← Zur Startseite
Architekturentscheidung / iOSBlackBerry UEM 12.24

Interne Web-App auf dem iPhone: Access oder Safari?

Zwei Wege zum selben Intranet. Unterschiedliche Grenzen für Daten, Anmeldung und Betrieb. Hier ist die Entscheidungskarte, die ich vor dem ersten Profil aufzeichnen würde.

Die Entscheidung in 30 Sekunden.

Bedingte Empfehlung

Wenn die Web-App und ihre Daten im BlackBerry-Dynamics-Bereich bleiben sollen, prüfen Sie BlackBerry Access zuerst. Wenn der native Browser gewünscht ist und die Daten- und Richtliniengrenzen das zulassen, prüfen Sie Safari mit Secure Connect Plus. In beiden Fällen bleibt die Anmeldung am Backend eine eigene Architekturentscheidung.

Das ist keine pauschale Produktempfehlung. Entscheidend sind Datenabfluss, unterstützte Authentifizierung, tatsächlich vorhandene Lizenzen und ein Pilot mit der Zielanwendung.

Ein Ziel. Drei Fragen.

Fiktives Beispiel: 500 verwaltete iPhones sollen intra.example erreichen. Der Dienst liegt hinter der Firewall und verwendet eine bestehende Unternehmensanmeldung. Beschäftigte sollen Seiten lesen und gelegentlich Dateien öffnen.

  1. Wo dürfen heruntergeladene Dateien anschließend liegen: im Dynamics-Container oder auch in iOS-Apps?
  2. Reicht ein erreichbarer Dienst, oder wird Anmeldung ohne erneute Kennworteingabe verlangt?
  3. Wer pflegt Domain, DNS, Zertifikate, UEM-Profil und Backend gemeinsam?

Die erste Frage trennt die Kandidaten. Die zweite trennt Netzwerkzugang von Single Sign-on. Die dritte entscheidet, ob der Weg später zuverlässig betrieben werden kann.

Die Wege sind nicht austauschbar.

A / kontrollierter App-BereichBlackBerry AccessDynamics Policy + Connectivity ProfileBlackBerry Proxy / gewählte RouteInterne Web-App → Backend-Anmeldung
B / nativer BrowserSafariSafari Domain + iOS Per-App VPNBlackBerry Connectivity / BSCPInterne Web-App → Backend-Anmeldung

Wichtig: Der Tunnel transportiert Verkehr. Er macht keine Webanmeldung automatisch zum SSO. Ein Domain-Match im VPN ist auch keine Regel, die Downloads in Safari auf einen Container begrenzt. Diese Grenzen müssen gesondert entworfen werden.

Wo welcher Weg gewinnt – und kostet.

PrüffrageBlackBerry AccessSafari + BSCP
DatenkontrolleDynamics-Container und Access-Regeln können die Weitergabe begrenzen. Die konkrete Policy entscheidet.Safari liegt außerhalb des Dynamics-Containers. iOS- und UEM-Schutzmaßnahmen gesondert bewerten.
ErlebnisEigene Browser-App; gut, wenn Dynamics-Apps und deren Links zusammenarbeiten sollen.Vertrauter iOS-Browser; Übergänge aus anderen Apps und erneute Anmeldung testen.
NetzwegDynamics Connectivity Profile legt erlaubte Ziele und Routing fest.Enterprise Connectivity Profile, Safari Domains und BSCP-DNS müssen zusammenpassen.
AnmeldungAccess kann mit Dynamics- und Backend-Verfahren zusammenspielen; KCD/Zertifikate sind eigene Voraussetzungen.Backend-Login bleibt nötig; SSO muss mit iOS, IdP und Web-App separat geprüft werden.
BetriebApp, Dynamics-Policy, Konnektivität und Proxy-Route pflegen.MDM-Zustand, VPN-Zuweisung, Connectivity-App, Domain und DNS pflegen.

Kosten und Lizenzrechte sind kundenspezifisch. Daraus lässt sich kein allgemeiner Preisvorteil ableiten.

Welche Stellschrauben hängen zusammen?

A · Access

  1. BlackBerry Access bereitstellen und der Pilotgruppe zuweisen.
  2. BlackBerry-Dynamics-Policy und Connectivity Profile zuordnen; Ziel-Domain und Route prüfen.
  3. Access-Einstellungen wie Enforce strict tunnel sowie Übergänge zu Safari bewusst wählen.
  4. Backend-Anmeldung mit Identitäts- und Web-Team testen. KCD ist keine reine Browser-Checkbox.

B · Safari + BSCP

  1. iPhone mit MDM controls aktivieren; Lizenz und BlackBerry Connectivity App prüfen.
  2. Unter Policies and Profiles → Networks and connections → Enterprise connectivity BSCP für die Pilotgruppe konfigurieren.
  3. iOS Per-App VPN und Safari domains auf die Ziel-Domain abstimmen; internes DNS für BSCP prüfen.
  4. Auf dem Gerät Domain-Aufruf, VPN-Auslösung, Namensauflösung und Backend-Login getrennt testen.

Die genauen Feldnamen und Wirkungen sind für UEM 12.24 dokumentiert. Je nach Aktivierungsart und Produktstand können zusätzliche Voraussetzungen gelten; im Pilot werden sie gegen die tatsächlich eingesetzte Version geprüft.

Ein Pilot, der eine Entscheidung trägt.

Ich würde zwei kleine Pilotgruppen mit derselben Web-App und denselben Aufgaben testen: öffnen, erneut anmelden, Link aus einer anderen App folgen, Datei herunterladen, Netz wechseln und Gerät neu starten. Für jeden Schritt werden Nutzeraufwand, Datenablage, erreichter Dienst, Fehlermeldung und verantwortliche Komponente notiert.

Das Ergebnis

Eine Seite mit gewähltem Weg, verworfenem Weg, Gründen und Restbedingungen. Dazu eine Abhängigkeitskarte mit App, UEM-Objekten, VPN/Proxy, DNS und Authentifizierung – für das Umsetzungs- und Betriebsteam verwendbar.

Stand und Quellen.

Autor: Axel Lenz. Redaktionsstand: 26. September 2026. Fachlicher Referenzstand: BlackBerry UEM 12.24 und BlackBerry Access 3.20; Apple Deployment-Dokumentation. Das Beispiel ist fiktiv und enthält keine Kundenkonfiguration. Die konkrete Empfehlung setzt einen Test der Zielversion und Zielanwendung voraus.