Product Documentation

Worx-API für iOS

Dec 20, 2017

Die XenMobile-API für iOS basiert auf Objective-C. Dieser Artikel bietet eine Übersicht über die XenMobile-APIs nach Feature sowie über die API-Definitionen.

Feature APIs
App-Verwaltung
 isAppManaged 



Interaktion mit Secure Hub
isMDXAccessManagerInstalled 
logonMdxWithFlag 
isAppLaunchedByWorxHome 
MDX-Richtlinien
 getValueOfPolicy 
Freigegebener Tresor
getVaultDataFromVault 
saveVaultData 
updateAndSynchronizeVaultItem 
updateAndSynchronizeVaultItems 
deleteVault 
deleteVaultWithError 
Benutzerdaten
 managedUserInformation 

Class MdxManager

Methoden

getValueOfPolicy

+(NSString*) getValueOfPolicy:(NSString*)policyName  
                        error:(NSError **) error;

Gibt für verwaltete Apps den von XenMobile-Administratoren festgelegten Richtlinienwert zurück. Gibt für nicht verwaltete Premium-Apps den in Applications/Citrix/MDXToolkit/data/MDXSDK/default_policies.xml. festgelegten Richtlinienwert zurück. Gibt für nicht verwaltete, allgemeine Apps nil zurück.

Parameter:

policyName: Richtlinienname, der in default_policies.xml gesucht werden soll.

Beispiel:

+(NSString*) getValueOfPolicy:(NSString*)DisableCamera error:(NSError **) error;

isMDXAccessManagerInstalled

 +(BOOL) isMDXAccessManagerInstalled: (NSError **) error; 

Prüft, ob Secure Hub installiert ist, was bedeutet, dass die MDX-Steuerung für die App aktiviert ist, selbst wenn die App nicht verwaltet wird. Gibt true zurück, wenn Secure Hub installiert ist.

isAppManaged

 +(BOOL) isAppManaged; 

Prüft, ob die App von MDX verwaltet wird, was bedeutet, dass das MDX-Richtlinienpaket in der App als XML-Datei eingebettet ist. Die Back-End-Infrastruktur von XenMobile (Schlüsseltresore) wird auf Datenverschlüsselungs-Teilschlüssel (geheime Schlüssel) abgefragt, die von MDX zum Verschlüsseln von App-Datenbankdaten verwendet werden (iOS 9). Gibt true zurück, wenn die App verwaltet wird.

logonMdxWithFlag

+(BOOL) logonMdxWithFlag:(BOOL)force  
                   error:(NSError**) error;

Initiiert eine MDX-Anmeldeanforderung für Secure Hub.

isAppLaunchedByWorxHome

 +(BOOL) isAppLaunchedByWorxHome; 

Prüft, ob eine App-übergreifende URL-Anforderung von Secure Hub oder einer anderen App auf dem Gerät stammt. Dies ist erforderlich, wenn eine App über MDX-Steuerkommunikationen unterrichtet sein muss. Unter iOS können Apps für bestimmte URL-Schemas registriert sein. Ein URL-Schema ist der Teil einer URL vor dem Doppelpunkt. Bei einer mit "http://..." beginnenden URL ist das Schema "http".

MDX-aktivierte Apps und Secure Hub kommunizieren mit benutzerdefinierten URL-Schemas. Zum Verarbeiten von mailto-URLs von anderen Apps benötigt Secure Mail beispielsweise das URL-Schema ctxmail. Zur Verarbeitung von http- oder https-URLs aus anderen Apps benötigt Secure Web das URL-Schema ctxmobilebrowser bzw. ctxmobilebrowsers. Einzelheiten zu der MDX-Richtlinien "App-URL-Schemas" und "Zulässige URLs" finden Sie in der MDX Toolkit-Dokumentation unter XenMobile MDX-Richtlinien für iOS-Apps.

Gibt genaue Ergebnisse zurück bei Abfrage zu jeder Zeit und überall während oder nach den folgenden UIApplication delegate event-Aufrufen:

  • Wenn die App vom Homebildschirm oder durch einen openURL-Aufruf geladen wird:
     application:willFinishLaunchingWithOptions: 
    application:didFinishLaunchingWithOptions: 
    applicationDidFinishLaunching: 
    
  • Wenn der Benutzer die App über den Homebildschirm aktiviert bzw. reaktiviert wird:
     applicationDidBecomeActive: 
    
    Wichtig: Während ApplicationWillEnterForeground: dürfen Sie keine Abfrage durchführen.
  • Wenn die App durch einen openURL-Aufruf geladen wird:
     application:openURL:sourceApplication:annotation:
     application:handleOpenURL: 
    

managedUserInformation

extern __attribute__((visibility ("default"))) NSString *const kXenMobileUsername; 
+(NSDictionary*) managedUserInformation;

Gibt eine Zeichenfolge mit dem Namen eines registrierten Benutzers einer mit MDX verwalteten App unabhängig von dessen Anmeldestatus zurück. Gibt eine leere Zeichenfolge zurück, wenn der Benutzer nicht registriert ist oder wenn die App nicht verwaltet wird oder nicht umschlossen ist.

Class XenMobileSharedKeychainVault

Methoden

initWithVaultName

- (instancetype) initWithVaultName:(NSString*)vaultName  
accessGroup:(NSString*)accessGroup; 

Initialisiert einen freigegebenen XenMobile-Tresor.

Verwenden Sie die API für den freigegebenen Tresor zum Verwalten der von Apps mit derselben Schlüsselbundgruppe gemeinsam verwendeten Inhalte. Sie können beispielsweise Benutzerzertifikate über eine registrierte App freigeben, sodass Apps Zertifikate aus dem Tresor statt von Secure Hub beziehen können.

Parameter:

vaultName: Name des freigegebenen XenMobile-Tresors

accessGroup: Name der Schlüsselbundgruppe Dies kann die Standard-MDX-Zugriffsgruppe TEAMID_A.appOriginalBundleID sein oder eine Schlüsselbundzugriffsgruppe, die Sie zur Freigabe von Daten zwischen Apps verwenden.

Tresordatentyp-Eigenschaften

@property(nonatomic,readonly) BOOL exists; 
@property(nonatomic,readonly) BOOL isAccessible; 
@property(nonatomic,strong) NSMutableDictionary* vaultData; 
Nach dem Initialisieren eines Tresors werden folgende Tresordatentyp-Eigenschaften zurückgegeben:
  • exists: gibt an, ob ein Tresor mit dem für vaultName angegebenen Namen gefunden wurde.
  • IsAccessible: gibt an, ob der Tresor in der angegebenen accessGroup ist und auf ihn zugegriffen werden kann.
  • vaultData: Inhalt des freigegebenen Tresors. Beim ersten Initialisieren des Tresors ist vaultData ein Nil-Wörterbuch.

getVaultDataFromVault

+ (NSDictionary*) getVaultDataFromVault:(NSString*)vaultName  
accessGroup:(NSString*)accessGroup error:(NSError *__autoreleasing *)error;

Liest Daten aus dem freigegebenen XenMobile-Tresor. Dies ist eine von drei Möglichkeiten zum Lesen der Tresordaten:

  • Direkte Verwendung von getVaultDataFromVault:accessGroup:error
  • Erstellen der XenMobileSharedKeychainVault-Instanz und Lesen der vaultData-Eigenschaft
  • Erstellen der XenMobileSharedKeychainVault-Instanz, Neuladen der Tresordaten mit -(BOOL) loadDataWithError:(NSError *__autoreleasing *)error; und Lesen der vaultData-Eigenschaft

Beispielcode finden Sie Beispiel für einen freigegebenen Tresor im vorliegenden Artikel.

Parameter:

vaultName: Name des freigegebenen XenMobile-Tresors

accessGroup: Name der Schlüsselbundgruppe Dies kann die Standard-MDX-Zugriffsgruppe TEAMID_A.appOriginalBundleID sein oder eine Schlüsselbundzugriffsgruppe, die Sie zur Freigabe von Daten zwischen Apps verwenden.

saveVaultData

+ (BOOL) saveVaultData:(NSDictionary*)vaultData toVault:(NSString*)vaultName 
accessGroup:(NSString*)accessGroup error:(NSError *__autoreleasing *)error;

Speichert die Daten im freigegebenen XenMobile-Tresor. Dies ist eine von drei Möglichkeiten zum Speichern der Tresordaten:

  • Direkte Verwendung von saveVaultData:toVault:accessGroup:error
  • Verwenden von updateAndSynchronizeVaultItem oder updateAndSynchronizeVaultItems (siehe nächste Tabellenzelle)
  • Verwenden von - (BOOL)synchronizeWithError:(NSError *__autoreleasing *)error; durch Erstellen der XenMobileSharedKeychainVault-Instanz, Laden der Tresordaten, Modifizieren der Tresordaten und Synchronisieren der Daten

Beispielcode finden Sie Beispiel für einen freigegebenen Tresor im vorliegenden Artikel.

Parameter:

vaultData: Daten, die im freigegebenen XenMobile-Tresor gespeichert werden sollen. Die Daten im Tresor sind ein Wörterbuch mit Schlüssel/Wert-Paaren, z. B. @{@"username":@"andreo"}.

vaultName: Name des freigegebenen XenMobile-Tresors

accessGroup: Name der Schlüsselbundgruppe Dies kann die Standard-MDX-Zugriffsgruppe TEAMID_A.appOriginalBundleID sein oder eine Schlüsselbundzugriffsgruppe, die Sie zur Freigabe von Daten zwischen Apps verwenden.

updateAndSynchronizeVaultItem

updateAndSynchronizeVaultItems

- (BOOL)updateAndSynchronizeVaultItem:(NSString*)vaultItem 
withValue:(id)itemValue error:(NSError *__autoreleasing *)error;
- (BOOL)updateAndSynchronizeVaultItems:(NSDictionary*)vaultItems 
error:(NSError *__autoreleasing *)error; 

Aktualisiert die Daten im freigegebenen XenMobile-Tresor. Zum Verwenden dieser Methode erstellen Sie die XenMobileSharedKeychainVault-Instanz und synchronisieren Sie sie durch Hinzufügen oder Aktualisieren von Tresordatenelementen. Enthält der vorhandene Tresoreintrag beispielsweise {a:123, b:234, c:305} und die API wird mit Daten zum Aktualisieren von {c:345, d:456} verwendet, werden die Tresordaten durch die API auf {a:123, b:234, c:345, d:456} aktualisiert. Beispielcode finden Sie Beispiel für einen freigegebenen Tresor im vorliegenden Artikel.

Unter saveVaultData weiter oben werden zwei weitere Möglichkeiten zum Speichern von Tresordaten aufgeführt.

Parameter:

vaultItem: einzelnes Schlüssel/Wert-Paar im Format @{@"username":@"andreo"}

vaultItems: Liste der Schlüssel/Wert-Paare

deleteVault

+ (BOOL) deleteVault:(NSString*)vaultName accessGroup:(NSString*)accessGroup  
error:(NSError *__autoreleasing *)error;

Löscht den angegebenen freigegebenen Tresor.

Parameter:

vaultName: Name des freigegebenen XenMobile-Tresors

accessGroup: Name der Schlüsselbundzugriffsgruppe, die von dem zu löschenden Tresor verwendet wird

deleteVaultWithError

 -(BOOL) deleteVaultWithError:(NSError *__autoreleasing *)error;

Löscht den freigegebenen Tresor, der über die XenMobileSharedKeychainVault-Instanz zurückgegeben wird. Sie müssen das Objekt nach dem Löschen mit deleteVaultWithError freigeben.

Beispiel für einen freigegebenen Tresor

#import "XenMobileSharedKeychainVault.h" 
 
@interface ClassA () 
... 
@property(nonatomic,strong) XenMobileSharedKeychainVault* XenMobileSharedKeychainVault; 
... 
@end 
 
@implementation ClassA 
... 
@synthesize XenMobileSharedKeychainVault = _XenMobileSharedKeychainVault; 
 
 
... 
#ifdef USE_CLASS_INSTANCE_METHODS 
-(XenMobileSharedKeychainVault*)XenMobileSharedKeychainVault 
{ 
if(_XenMobileSharedKeychainVault==nil) { 
_XenMobileSharedKeychainVault = [[XenMobileSharedKeychainVault alloc]  
      initWithVaultName:  
      accessGroup:kXenMobileKeychainAccessGroup]; 
} 
return _XenMobileSharedKeychainVault; 
} 
#endif 
 
-(void)read 
{ 
NSError* error=nil; 
#ifdef USE_CLASS_INSTANCE_METHODS 
NSDictionary* vaultDictionary = nil; 
if([self.XenMobileSharedKeychainVault loadDataWithError:&error]) { 
vaultDictionary = [self.XenMobileSharedKeychainVault vaultData]; 
} 
#else 
NSDictionary* vaultDictionary = [XenMobileSharedKeychainVault  
      getVaultDataFromVault:  
      accessGroup:kXenMobileKeychainAccessGroup error:&error]; 
#endif 
 
} 
 
-(void)save 
{ 
NSError* error=nil; 
/// check error handling here... 
 
NSDictionary* dictToSave = @{}; 
#ifdef USE_CLASS_INSTANCE_METHODS 
#ifdef USE_CLASS_INSTANCE_METHODS_TO_UPDATE 
BOOL result = [self.XenMobileSharedKeychainVault  
      updateAndSynchronizeVaultItems:dictToSave error:&error]; 
#else 
self.XenMobileSharedKeychainVault.vaultData = [NSMutableDictionary  
      dictionaryWithDictionary:dictToSave]; 
BOOL result = [self.XenMobileSharedKeychainVault synchronizeWithError:&error]; 
#endif 
#else 
BOOL result = [XenMobileSharedKeychainVault  
      saveVaultData:dictToSave toVault:  
      accessGroup:kXenMobileKeychainAccessGroup error:&error]; 
#endif 
 
} 
 
-(void)delete 
{ 
NSError* error=nil; 
#ifdef USE_CLASS_INSTANCE_METHODS 
BOOL result = [self.XenMobileSharedKeychainVault deleteVaultWithError:&error]; 
#else 
BOOL result = [XenMobileSharedKeychainVault deleteVault:  
      accessGroup:kXenMobileKeychainAccessGroup error:&error]; 
#endif 
 
} 
 
... 
 
@end