Im Artikel Mobile Lösungen – Mehr als nur Apps dank Cloud Backend wurden der Kontext einer mobilen Lösung, die Herausforderungen an Entwickler und die Mobile Services aus Architektursicht umrissen.
In diesem Artikel wird gezeigt, wie der Zugriff auf die Mobile Services mittels Authentisierung eingeschränkt werden kann.
Das Modul Auth resp. Identity
Im Windows Azure Management Portal können unter dem jeweiligen Mobile Service über das “Identity”-Tab die Identity Provider konfiguriert werden, welche bei der Sicherheitseinstellung Nur authentisierte Benutzer verwendet und dem User-Objekt der Scripts übergeben werden. Die folgende Abbildung zeigt, wie die Tabelle “Project” nur authentisierten Benutzern lesenden Zugriff gewährt.
Zugriffseinstellungen für Azure Mobile Services Scripts
Bei der Authentisierung wird Claims-based-Authentication verwendet, daher der Benutzer wird zuerst auf eine Seite eines Identity-Providers weitergeleitet, der die Authentisierung durchführt und den Benutzer identifiziert. Gegenüber der App, bestätigt der Identity-Provider dann die Gültigkeit des Benutzers.
Es stehen folgende Identity-Provider zur Verfügung:
- microsoft account
- windows azure active directory
Während die ersten vier Identity-Provider Azure-fremde Dienste zur Authentisierung verwenden, wird Azure Active Directory gleich im Azure Portal konfiguriert und fällt damit unter die eigene Kontrolle. Dies hat einen entscheidenden Einfluss auf den Kontext der Anwendung. Die externen Identity-Provider dienen lediglich der Wiedererkennung eines Benutzer, so dass ihm seine Daten zugeordnet werden können. Es ist aber nur mit einigem Zusatzaufwand möglich, die Daten einer realen Person zuzuordnen. Auch haben wir hier nicht die Kontrolle über die Aktivierung/Deaktivierung von Accounts. Benutzer können hier nur mittels selbst gestrickter Blacklist-Lösung ausgeschlossen werden. Doch selbst dann hindert niemand den Benutzer daran, bei einem dieser öffentlichen Dienste einen neuen Account zu erstellen.
Ganz anders verhält es sich mit dem Azure Active Directory. Hier bestimmen wir (bzw. unsere Administratoren) wer einen gültigen Account besitzt. Bezogen auf den Kontext, bedeutet dies, dass die ersten vier Identity-Provider sich hervorragend für Consumer-Apps eignen, da hier lediglich Daten einem Account zugeordnet werden müssen, ohne dass die Person bekannt ist. Sie dienen nur der Zuordnung von Daten zu einem Login, damit der Benutzer immer wieder seine Daten hat. Wir haben es hier also mit einem unbeschränkten Benutzerkreis ausserhalb unserer Kontrolle zu tun.
Azure Active Directory wird in einem ganz anderen Kontext verwendet. Hier ist nicht der Benutzer selbst für die Erstellung seines Accounts verantwortlich, sondern der Account wird ihm von einer Organisation zur Verfügung gestellt. Wir haben es hier also mit einem beschränkten und kontrollierbaren Benutzerkreis zu tun.
Die folgende Abbildung zeigt, die Filterung der Projekte für einen bestimmten User anhand seiner Active Directory ObjectId im Read-Table-Script der Project-Tabelle:
Filtern der Daten nach AAD ObjectId im Read-Table-Script für die Project-Tabelle
Windows Azure Active Directory
Das Windows Azure Active Directory kurz AAD bietet ein Active Directory in der Cloud, welches sich mit einem lokalen on-premise Active Directory synchronisieren lässt. Damit steht mobilen Unternehmenslösungen nichts mehr im Wege. Benutzer können sich somit auch bei Mobile-Apps über ihr Firmen-Login authentisieren. Da sich auch Websites einfach mit AAD integrieren lassen, steht einer gesamten Unternehmenslösung in der Cloud nichts mehr im Wege.
Wie man AAD aufsetzt zeigt der Artikel Register your apps to use a Windows Azure Active Directory Account login.
Umsetzung
Client
Das Mobile Services SDK bietet auf dem Client die Methode LoginAsync, welcher als Parameter der zu verwendenden Identity-Provider übergeben wird und die ein MobileServiceUserObjekt zurück liefert. Dieses sollte dem CurrentUser des MobileServices zugewiesen werden, damit es bei jedem HTTP-Aufruf an den MobileService mitgegeben wird.
Für Twitter bessieht dies wie folgt aus:
App.MobileService.CurrentUser = await App.MobileService.LoginAsync(MobileServiceAuthenticationProvider.Twitter);
Für Azure Active Directory sieht dies in der Preview wie folgt aus, da noch kein MobileServiceAuthenticationProvider-Enum-Wert existiert:
App.MobileService.CurrentUser = await App.MobileService.LoginAsync("aad");
Die Klasse MobileServiceUser bietet nur einen abstrakten Behälter für die UserId und das MobileServiceAuthenticationToken. Dies ist nötig damit für alle unterschiedlichen Identity-Provider ein einheitliches Interface besteht.
Soll der User gespeichert werden, damit er sich beim nächsten Start der App nicht erneut mit Benutzername und Passwort neu authentisieren muss, können die beiden Properties des MobileServiceUser-Objekt im PasswordVault (Windows Store Apps) oder verschlüsselt mittels ProtectData im IsolatedStorage (Windows Phone) gespeichert werden und beim nächsten Start damit ein neues MobileServiceUser-Objekt erstellt und wieder dem App.MobileService.CurrentUser zugewiesen werden, der von jedem Request mitgegeben wird.
Da es sich beim MobileServiceAuthenticationToken um ein Secret handelt, sollte dies unbedingt wie beschrieben verschlüsselt werden.
Leider kann über das MobileServiceUser-Objekt nicht auf die Eigenschaften des Users wie z.B. die E-Mail-Adresse, der Name, etc. zugegriffen werden. Dies ist nur aus dem Backend möglich.
Backend
In den Table- und API-Scripts im Mobile-Service steht der authentisierte Benutzer als user-Parameter des Scripts resp. als user-Property des Request-Objekts zur Verfügung. Anders als im Client, kann hier über die Methode getIdentity des user-Objekts auf die Provider-spezifischen Attribute zugegriffen werden. Für AAD existiert dazu das aad-Property des identities Callback-Parameters, welche die Active Directory spezifischen Parameter hat. Der folgende Code zeigt, wie die Object ID (oid) des Users gelesen werden kann:
user.getIdentities({
success: function (identities) {
var objectId = identities.aad.oid;
console.log(objectId);
}
});
Die objectId kann nun verwendet werden, um die Daten für einen einzelnen User herauszufiltern.
Fazit
Mit dem Windows Azure Active Directory ist es nun einfach möglich, mobile Geschäftsanwendungen zu erstellen. Als Entwickler hat man sehr schnell ein Active Directory erstellt und konfiguriert und kann gleich loslegen, ohne zuerst einen Windows Server aufsetzen und konfigurieren zu müssen.
Dieser Artikel sollte Ihnen einen ersten Überblick über die Authentisierung in Mobile Services und im Speziellen mit Azure Active Directory geben. Falls Sie Fragen haben, beraten wir Sie gerne. Sie erreichen uns über http://www.noser.com/de/kontakt.
Weitere Details zum Thema erfahren Sie auch auf der unserem Anlass Enable your Developers to go mobile with the Cloud am 10. April 2014 im Technorama in Winterthur.
