Mit SharePoint 2016 und SharePoint online geht Microsoft den Weg Richtung Cloud und vor allem den Weg der hybriden Szenarien konsequent weiter. Umso öfter wird man dadurch aber gerade in der Entwicklung mit Begriffen konfrontiert, die immer wieder auch zu Verwirrung führen können und scheinbar nicht so genau einzuordnen sind. So wurde ich in der Vergangenheit schon mehrmals mit folgenden Fragen konfrontiert:
- Warum brauche ich OAuth, wenn ich Azure AD nutze?
- Was ist OpenID, ist das nicht OAuth?
- Wofür brauch ich ADAL wenn ich Azure AD nutze?
- OWIN? Was soll das sein?
Daher versuche ich hier einen kurzen Abriss über diese Begriffe, vor allem aus Entwicklersicht zu geben und dem interessierten Leser ein paar Links zur Verfügung zu stellen, um mehr zu erfahren bzw. sich in die Themen zu vertiefen.
Azure Active Directory (Azure AD) ist wohl den meisten bekannt und es sind wohl auch die meisten damit vertraut. Damit ist im Grunde der von Microsoft zur Verfügung stehende cloudbasierter Identitätsverwaltungs- und Verzeichnisdienst gemeint. Mit dem man beispielsweise relativ leicht, Benutzern, wie z.B. Mitarbeiter und externen Partnern, Zugriff im Stile von Single Sign-On (SSO) auf verschiedenste Cloud Anwendungen, wie z.B. Office 365 / SharePoint online gewähren kann. Aus Entwicklersicht ist es somit einfacher Anwendungen zu entwickeln, die im Hintergrund eine Identitätsverwaltung benötigen. Mittels Azure ADSync können auch on-premisses Active Directory Konten nach Azure AD synchronisiert werden. Dies ist hinlänglich bekannt und wer mehr Details wissen möchte, sei auf Microsofts Webseite zum Thema Microsoft Azure verwiesen.
Ein klein wenig komplizierte wird die Sache, wenn man OAuth und OpenID betrachtet. Open Authentication (OAuth) stellt ein offenes Framework dar, das zum Ziel hat, Anwendungen (Client Apps) Zugriff auf HTTP Diensten zu ermöglichen. Entweder im Auftrag eines Benutzers auf Web-Ressourcen zuzugreifen oder direkt als App selbst, Zugriff auf eine Ressource zu erhalten. Details findet man unter http://tools.ietf.org/html/rfc6749. Im speziellen ist hier die Version 2.0 von OAuth gemeint. Mit Hilfe von sogenannten Access Tokens wird hier Zugriff auf Ressourcen gewährt. Je nach implementierten OAuth 2.0 Flow kann es sein, dass ein sogenannter Code Grant angefordert wird. Erst mit dem Code Grant kann dann ein Access Token angefordert werden, mit dem dann letztlich eine Web-Ressource abgefragt werden kann. Ein Access Token wird immer gemeinsam mit einem Refresh Token an die App ausgestellt. Dieses Refresh Token wird dann eingesetzt, wenn ein Access Token zeitlich bereits abgelaufen ist. Dadurch ist es nämlich möglich, ein neues Access Token anzufordern, ohne das der Benutzer das im Front-End mitbekommt.
Kurz gesagt, OAuth 2.0 deckt also die Autorisierung ab. Das mag jetzt vielleicht etwas überraschend sein. Tatsächlich wird aber OpenID Connect benötigt, um einen Benutzer zu identifzieren/authentifzieren. Bei OpenID Connect handelt es sich um einen zusätzlichen „Layer“ der auf OAuth 2.0 aufsetzt und sich um das Identitätsmanagement kümmert. Anders gesagt, Azure AD unterstützt somit OAuth 2.0 und auch OpenID. Als Entwickler sollte man das wissen, wenn Anwendungen für Office 365 und Azure AD entwickelt werden sollen.
Jetzt bleibt noch zu klären, was es mit der Active Directory Authentication Library (ADAL) auf sich hat. Um es auch hier kurz zu machen: ADAL ist eine Authentifizierungs-Library für .NET, iOS, Android, Java, JavaScript usw., die zum Ziel hat, die Authentifizierung zu vereinfachen, um sich als Entwickler nicht im Detail, um die Security kümmern zu müssen. Als Entwickler muss man also kein Security Experte sein, um für z.B. eine App ein Access Token für API Aufrufe zu bekommen. So ist es damit auch möglich Tokens zu cachen oder auch den Refresh Ablauf, um neue Access Tokens zu erhalten, zu automatisieren. Benötigt man ADAL für sein Visual Studio Projekt, gibt es natürlich auch ein nuget Package, das mittels Install-Package Microsoft.IdentityModel.Clients.ActiveDirectory ganz einfach verwendet werden kann.
Ja, und dann gibt es auch noch das Open Web Interface for .NET (OWIN). Dabei handelt sich ebenfalls um einen offenen Standard, der ein Interface zwischen Web Servern und Web Anwendungen definiert, um eine Entkopplung dieser beiden zu erreichen. Dadurch wird es leichter Anwendungen oder Services für das Web zu entwickeln. Beispielsweise kann mittels OWIN ein neuer Authentifzierungs Vorgang (OAuth2.0) angestoßen werden (HttpContext.Current.GetOwinContext().Authentication.Challenge(…)) um ein neues Access Token zu erhalten. Natürlich ist mit OWIN noch viel viel, ja sogar sehr viel mehr möglich. Die ASP.NET MVC und WebAPI Entwickler kennen das natürlich schon länger und nutzen es auch für ihre Anwendungen bzw. Services.
Nun kann sich der aufmerksame Leser natürlich fragen, warum soll mich das als SharePoint Entwickler interessieren, ich entwickle meine full-trusted Lösungen? Nun die Frage ist legitim, full-trusted Lösungen wird es auch weiterhin geben, so wie es auch Kunden geben wird, die aus nachvollziehbaren Gründen die Cloud nicht nutzen können oder aus datenschutzrechtlichen Gründen nicht nutzen dürfen. Dennoch ist der Weg in die Cloud da geebnet. Vor allem hybride Szenarien nehmen an Bedeutung zu. Lösungen werden für die Zukunft entwickelt und die Möglichkeiten, die die Cloud und hybride Szenarien dafür bieten, sind ungleich größer und auch flexibler.
Die Besucher unseres Kundenevents Next Destination > SharePoint 2016, können sich eventuell noch an das gezeigte Beispiel mit dem Projektportal in SharePoint online erinnern, das ausgehend von einer on-premises SharePoint Liste angelegt wurde. Um solche Lösungen zu entwickeln, muss man sich als Entwickler mit diesen Themen auseinandersetzen, um die Hintergründe zu verstehen und auch Entscheidungen für Architekturen, die umgesetzt werden sollen, begründen zu können.
Dazu möchte ich abschließend noch ein Beispiel geben. Wenn man z.B. SharePoint Add-Ins für SharePoint online entwickelt muss man demnach schon vorher wissen, ob es notwendig sein wird auch andere APIs der Office 365 Welt nutzen zu wollen. Schreibt man ein Add-In für SharePoint steht auch „nur“ die API von SharePoint (online) zur Verfügung. Möchte man hingegen z.B. die MS Office Graph API oder noch mehr, das gesamte „Office 365 Ökosystem“ nutzen, sollte man darüber nachdenken, eine Azure AD App zu implementieren und eventuell über REST Services Funktionen einem SharePoint Add-In zur Verfügung stellen.
Damit bin ich auch schon am Ende meines Blog-Artikels. Ich hoffe, dass ich einen guten Überblick geben konnte, womit wir uns aus Entwicklersicht in Zukunft weiter beschäftigen müssen und werden. Eines kann ich auf jeden Fall sagen, es macht mit verdammt viel Spaß J.
