Azure B2C : Adding Azure Active Directory (AAD) via custom policies

As I write these are in preview.

The documentation is here.

The AAD guide is here.

And the obligatory warning:

"Custom policies are designed primarily for identity pros who need to address complex scenarios. For most scenarios, we recommend that you use Azure Active Directory B2C built-in policies. Built-in policies are easier to set up for your configuration. You can use built-in and custom policies in the same Azure Active Directory B2C tenant. To learn more, see the overview of custom policies."

and again:

"Custom policy editing is not for everyone. The learning curve is demanding, the startup time is longer, and future changes to custom policies will require similar expertise to maintain. Built-in policies should be carefully considered first for your scenario before using custom policies."

I don't necessarily agree with this and am somewhat puzzled as to why they push this so hard.

The aim should be to encourage people to have a crack at it and learn something rather than scare them away.

I would spend some time reading through the getting started guide and get an overview of how the XML files work, how to upload them etc.

The big drawback about all of these guides is that they publish snippets of XML and it's always hard to figure out the context i.e. where they go in the document and how they relate to the other sections.

So I decided to publish all five files as gists (suitably redacted!).

I have three add-ons:

• Facebook - from the default policy 
• ADFS - added but doesn't work because of the self-signed certificate
• AAD - which works

Note that this was for a PoC where I was just looking at authentication. I haven't looked at the claims passed etc.

Also I did not have an actual application. I just tested using the "Run Now" button.

My B2C page looks like:

Also note that I added Application Insights which I strongly recommend for debugging (in SignUpOrSigninWithAAD.xml).

Enjoy!

Azure B2C : Tracking errors

I've posted before on how crucial Application Insights is to troubleshooting B2C custom policies.

Once you had got it setup, you need to wait about 5 minutes and then run something like:

traces

This displays all the data. You can sort by clicking on the "timestamp column".

 Expand the "message" section.

Expand the "FatalException" section.

and you'll see the error.

If you want to filter the errors, try something like:

traces
| where severityLevel > 0 and message contains "Exception"

Enjoy!

AAD : Beware the difference in the V1.0 and V2.0 endpoints

The V2.0 endpoint is the endpoint that allows you to sign in with the converged Microsoft and Azure Active Directory accounts.

From an OpenID / OAuth perspective, the discovery documents can be found at:

V1.0:

https://login.microsoftonline.com/common/.well-known/openid-configuration

V2.0:

https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration

Notice the extra "V2.0".

If we look at the keys, we see for V1.0:

https://login.microsoftonline.com/common/discovery/keys

And for V2.0 :

https://login.microsoftonline.com/common/discovery/v2.0/keys

You will notice that V2.0 has four signing keys while v1.0 only has two.

V2.0 is the endpoint used by B2C.

Don't assume that tokens signed by Azure AD (V1.0) are also acceptable for B2C (V2.0) and vice versa.

This will be true when AAD and B2C are merged at some point in the future but right now it's a gotcha!

Enjoy!

AAD : The V2.0 endpoints

I've been helping a few people lately with this and I see the same few issues that continually trip people up.

Table to help decide whether to use the v2.0 endpoints or not.

And note that currently the "Resource owner password credentials" grant is not supported.

Have a look at the current restrictions.

The endpoints are different:

https://login.microsoftonline.com/common/oauth2/v2.0/authorize
https://login.microsoftonline.com/common/oauth2/v2.0/token

The scopes are different. They now take the form of a URI e.g.

"scope": "https://outlook.office.com/mail.read https://outlook.office.com/mail.send"

You can use the default scope e.g.

https://graph.microsoft.com/.default

This means that the application uses the pre-defined scope.

You need to use the Application Registration Portal to register the application. Don't use the usual Azure AD Applications screens.

You need to cater for the admin. consent endpoint if you want to grant consent for the application to anyone who can authenticate.

Use the MSAL library rather than the ADAL library.

Enjoy!

Swagger : Using Swagger for Implicit Grant on Azure AD

Review my previous post - Swagger : Using Swagger for Implicit Grant on ADFS 4.0.

This builds on that.

Given that I couldn't get it working on ADFS, I thought I would try Azure AD (AAD).

One of the problems with AAD is that the web API calls are protected so if you want to use Swagger, authentication always fails.

I started with the OpenID Connect - web app. with web API sample. Follow the details to configure the web app. and the web API in AAD.

I'm running this on my PC.

This is a standard "adding items to a ToDo list" project.

Then I added swashbuckle etc. as per my post above.

As always, the gist is here.

Note that AAD needs the "resource" parameter, hence the extra line:

additionalQueryStringParams: new Dictionary() { { "resource", "https://azure-tenant.onmicrosoft.com/TodoListService" } }

Also, you do not need the clientSecret for implicit flow. This is because implicit flow is normally used for SPA and the secret key could be easily exposed in the JavaScript.

Looking at the ToDoListController:

if (ClaimsPrincipal.Current.FindFirst("http://schemas.microsoft.com/identity/claims/scope").Value != "user_impersonation")
            {
                throw new HttpResponseException(new HttpResponseMessage { StatusCode = HttpStatusCode.Unauthorized, ReasonPhrase = "The Scope claim does not contain 'user_impersonation' or scope claim not found" });
            }

            if (null != todo && !string.IsNullOrWhiteSpace(todo.Title))
            {
                todoBag.Add(new TodoItem { Title = todo.Title, Owner = ClaimsPrincipal.Current.FindFirst(ClaimTypes.NameIdentifier).Value });
            }

So we need a scope of  "user_impersonation" and we need a NameID claim.

We get the OAuth endpoints from the "View Endpoints" button in AAD. (Using the classic portal).

We need to add Swagger as an Azure AD application - the normal web site flow.

Ensure there is  "Reply URL" for:

  https://my pc/TodoListService/swagger/ui/o2c-html

We have to give this application permission to access the ToDoListService:

So what we are going to do is to use the same web API back-end but use Swagger as the web app.

Since there is a common back end, the ToDo list should reflect across both.

From the project, we add item "1234".

Now we try with Swagger.

and we get the 401.

So we click the red exclamation mark and we see:

Click "Authorize" and then authenticate with AAD.

Problem: we need to explicitly enable implicit flow. You do this via the manifest and then update:

"oauth2AllowImplicitFlow": true,

Now if we break-point at the NameID code and then check which attribute this matches in the token, we''ll see it matches the "sub":

...
"scp": "user_impersonation",
"sub": "nYa...Zow",

...

The OWIN classes must do this mapping internally viz. "sub" --> "NameID".


Now that we have authenticated, let's try again.

and we see that we get back the "1234" that we created with the web app.

Now we add a new item using the POST.

The object requires a "Title" and an "Owner" so we need to build one that looks like:

{
    "Title": "5678",
    "Owner": "nYa...Zow"
}

That returns OK and when we do another GET, we see:

[
  {
    "Title": "5678",
    "Owner": "nYa...Zow"
  },
  {
    "Title": "1234",
    "Owner": "nYa...Zow"
  }
]

Now go back to our web app.

so it all lines up.


Enjoy!

AAD : Advanced user lifecycle management

Done so much ADFS stuff lately, it's cool to look at Azure AD for a change!

Good overview

So to provision users into Azure AD as per above:

"Azure AD provides automated, advanced user life-cycle management by using dynamic group membership rules and application management capabilities. Here’s more detail:

• For organisations with on-premises HR, Microsoft Identity Manager establishes user identities in Windows Server Active Directory.
• For organisations with software as a service (SaaS)–delivered HR, Azure AD currently integrates with Workday.
• Azure AD Connect syncs users and groups between Windows Server Active Directory and Azure AD.
• Azure AD provides group-based automated licensing for Office 365 and other Microsoft on line services."

Or you could use the Graph API.

Or manually via the portal.

Or via B2B.

What is really needed as well is a browser-based provisioning service into Azure AD that does not require the use of the Azure portal, admin rights. etc.

Extra brownie points for adding delegated admin. as well :-)

Enjoy!

 

Postman : Azure AD and Implicit Flow

I've been playing around with this and thought it would be worthwhile to document  the journey.

I have a web application in Azure AD and this application calls a web API.

The web application has permission to call the web API.

I want to use the implicit grant.

This is not supported OOTB :

AADSTS70005: response_type 'token' is not supported for the application

You need to update the manifest as per ADAL JS - response_type=“token” is not supported.

After sorting that out, my first call was:

https://login.microsoftonline.com/[tenant id]/oauth2/authorize?client_id=[client id]&response_type=token&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F

This resulted in:

http://localhost/myapp/#error=invalid_resource&error_description=AADSTS50001%3a+Resource+identifier+is+not+provided...

OK - so I need a "resource" parameter - let's make it the same as the response type.

https://login.microsoftonline.com/[tenant id]/oauth2/authorize?client_id=[client id]&response_type=token&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F&resource=http%3A%2F%2Flocalhost%2Fmyapp%2F 

This resulted in:

http://localhost/myapp/#error=invalid_resource&error_description=AADSTS50001%3a+The+application+named+http%3a%2f%2flocalhost%2fmyapp%2f+was+not+found+in+the+tenant+named+[tenant id]/++This+can+happen+if+the+application+has+not+been+installed+by+the+administrator+of+the
+tenant+or+consented+to+by+any+user+in+the+tenant.
++You+might+have+sent+your+authentication+request+to+the+wrong+tenant....

So maybe I need the "APP ID URI" of the web application?

https://login.microsoftonline.com/[tenant id]/oauth2/authorize?client_id=[client id]&response_type=token&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F&resource=https://www.getpostman.com/oauth2/callback

This resulted in:

http://localhost/myapp/#error=invalid_request&error_description=AADSTS90027%3a+The+client+%[client id]%27+and+resource+%27https%3a%2f%2fwww.getpostman.com%2foauth2%2fcallback%27+identify+the+same+application...

Aha - so maybe I need the "APP ID URI" of the web API?

https://login.microsoftonline.com/[tenant id]/oauth2/authorize?client_id=[client id]&response_type=token&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F&resource=https://xxx.onmicrosoft.com/xxxService 

This resulted in:

http://localhost/myapp/#access_token=eyJ...Cpw&token_type=Bearer&expires_in=3599&session_state=6e7...203 

Bingo!

I've obviously over-egged this a bit but you can see how you can work through the issues and figure out what's wrong based on the error messages.

The errors you get back from Azure AD  are an order of magnitude better than they used to be :-)

Note that the implicit grant does not return a refresh token because the browser has no means of keeping it private.

Enjoy!

Postman : Using Postman to get "Userinfo" on Azure AD

I got this idea from v2.0 Protocols - OAuth 2.0 Authorization Code Flow that has "Run in Postman" buttons that load Postman collections.

So I made my own which you can find in this gist.

This uses OpenID Connect / OAuth 2.0.

It has three steps.

The first you have to customise for your clientID etc. and then run in a browser.

Then copy / paste the code from the reply into the second, customise for your clientID etc. and click "Run".

This returns an access token, an ID token and a refresh token.

(You can see what's in them by copy / paste the access / ID token into jwt.io).

The code inside the collection automatically sets up the token for the third step so all you have to do is press "Run".

You will see the full "Userinfo".

There are full instructions in the collection.

Enjoy!

OAuth2 : Verifying the Azure AD JWT signature

Was having a look at Azure AD and JWT tokens and was wondering how the signature was calculated?

I use this useful utility from Auth0 to decode the tokens.

So I paste either the access or identity token into the "Encoded" box and set the "Algorithm" drop down to "RS256" (as below in bold). Problem is the signature is invalid. So how do I verify it.?

Looking at a typical token header,

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "MnC_VZcATfM5pOYiJHMba9goEKY"
}

we see the algorithm and the reference to the public key.

In Azure AD, we can get the OAuth 2.0 details from the discovery endpoint viz.

https://login.microsoftonline.com/common/.well-known/openid-configuration

and that gives us:

"authorization_endpoint": "https://login.microsoftonline.com/common/oauth2/

    authorize",
    "token_endpoint": "https://login.microsoftonline.com/common/oauth2/token",
    "token_endpoint_auth_methods_supported": [
        "client_secret_post",
        "private_key_jwt"
    ],
    "jwks_uri": "https://login.microsoftonline.com/common/discovery/keys",
    "response_modes_supported": [
        "query",
        "fragment",
        "form_post"
    ],

... 

Now if we go to the key endpoint (bold above), we see:

"keys": [
        {
            "kty": "RSA",
            "use": "sig",
            "kid": "MnC_VZcATfM5pOYiJHMba9goEKY",
            "x5t": "MnC_VZcATfM5pOYiJHMba9goEKY",
            "n": "vIqz-4-ER_vNWLON9yv8hIYV737...NOhfXgelixLUQ",
            "e": "AQAB",
            "x5c": [
                "MIIC4jCCAc...H3/bKkLSuDaKLWSqMhozdhXsIIKvJQ=="
            ]
        },

... 

There is  more than one of these sets. You need the one whose "kid" matches the "kid" in the JWT header.

The "x5c" is the public key. Copy the entire string e.g. from "MIIC" to "JQ==" in the above to Notepad.

Now add:

"-----BEGIN CERTIFICATE-----"

at the beginning and add:

"-----END CERTIFICATE-----"

at the end.

You should have something like:

-----BEGIN CERTIFICATE-----
MIIC4jCCAc
...
H3/bKkLSuDaKLWSqMhozdhXsIIKvJQ==
-----END CERTIFICATE-----

Now paste that into the "Verify Signature" box and you'll see the "Signature Verified" message at the bottom in blue.

Enjoy!

AAD : Authentication with .NET Core

This is for Azure Active Directory (AD) with .NET Core 1.0 and VS 2015 Update 3.

Download the .NET Core files for Windows from Core#windows.

We want to write a web application using .NET Core that authenticates with Azure AD.

Then we want to select a web application and we also "Change Authentication" to "Work and School Accounts" and "Cloud - Single Organization".

Note there is no "on-premises" option using ADFS.

You have to enter your Azure tenant and authenticate and then the project is created together with  an application in Azure AD.

The project structure looks much the same as the normal ASP.NET project created this way wrt. the Controller and Views.

Also the authentication is via OpenID Connect as you would expect.

One difference is that the configurable options are no longer in web.config but rather in appsettings.json.

Also, the tried and tested way we have used for years i.e.

ViewBag.ClaimsIdentity = Thread.CurrentPrincipal.Identity;

no longer compiles. There's tons of discussion around this but you can find the code I used in this gist.

The claims then display in the "Contact" tab in the normal way.

Enjoy!

AAD : Migrating JWT to claims.

Both AAD and ADFS 4.0 (Server 2016) have support for JWT - normally from OpenID Connect / OAuth but also from WS-Fed (via ADFS).

On the RP side, you get a claims principal that contains some of the information that's in the JWT but it's hard to figure out the relationship.

You can see some of it via Get-ADFSClaimDescription with PowerShell.

e.g.

ClaimType  : http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier
IsAccepted : True
IsOffered  : True
IsRequired : False
Name       : Name ID
ShortName  : sub
Notes      : The SAML name identifier of the user

You can see more info. here.

So "sub" in the JWT contains the NameID and this then is transformed to a NameID claim by the middleware.

Enjoy!

AAD : Easy Auth

This is for Azure Active Directory (AD).

"Easy Auth" is what the Authentication / Authorization feature in App Services is called.

The idea behind this is that you can have an Azure website and using this feature you can add authentication to it with a few clicks,

You do not have to use NuGet OWIN packages or anything similar. No code is involved.

Essentially it uses an "agent" feature as per Architecture of Azure App Service Authentication / Authorization. There's a native IIS module that sits outside of your application and all requests are directed through this. If not authenticated then you get redirected to the Azure AD login screen. (Recall that Azure web sites actually run on IIS).

You don't not have to add an application to Azure AD. It's all done for you.

So how does it work?

I used VS 2013.

New Project / ASP.NET Web Application. Ensure MVC is checked.

Click the "Change Authentication" button and select the "No Authentication" radio button.

So now we have a bare-bones project with no built-in authentication.

Now deploy to Azure (there are tons of posts around this so I'll skip the details).

At this point you have a web site - e.g. https://easyauth.azurewebsites.net/.

There is no entry for this in Azure AD.

In the new portal, click on "App Services", then the app service (the web site) and then "Settings".

Select "Authentication / Authorization" as above.

Turn on Authentication. choose "Login with Azure Active Directory" from the drop-down and then click the "Azure Active Directory" authentication provider.



Then select the "Express" setting.

Save out.

Now if you go to the old (classic) portal under "Azure Active Directory" you'll see that you have a new application.

You should be able to navigate to your website and the first thing it should do is ask you to authenticate.

Except - it doesn't!

Back to Mr. Google and I found this: How to configure your App Service application to use Azure Active Directory login.

As per the section: "(Alternative method) Manually configure Azure Active Directory with advanced settings", you need to click the Advanced section (not the Express) and add:

/.auth/login/aad/callback

to the "Reply URL"  in Azure Active Directory. Don't worry about all the stuff about actually creating the application - that's already been done.

And then, lo and behold, it worked!

Enjoy!

AAD : MSAL : Microsoft Authentication Library

This was announced at \\Build in Vittorio's presentation:

Microsoft Identity: State of the Union and Future Direction

and is further described here:

Microsoft Identity at //build/ 2016

"MSAL is a unified library that helps you to develop applications that work with Microsoft Accounts, Azure AD accounts and Azure AD B2C users indifferently – all in a single, streamlined programming model!"

So it targets the "converged model".

It's a "successor" to ADAL with the important proviso that it will not work with ADFS and the original Azure AD.

"ADAL is and remains the main means you have to work with the original Azure AD and with ADFS, which aren’t supported by MSAL. If you need a token for a service that today accepts only tokens from the original Azure AD, such as the Azure ARM API, you’ll want to keep using ADAL."

The NuGet package is here. Note that it is a prerelease.

The other change is that there is a new application portal at:

apps.dev.microsoft.com

The article has links to some sample code but I found the web app. one confusing.

I think Integrate Microsoft identity and the Microsoft Graph into a web application using OpenID Connect is a better sample (or another view: Integrate Microsoft identity and the Microsoft Graph into a web application using OpenID Connect).

Running the sample, we see:

So we can choose either the Microsoft account (MSA) (aka LiveID) or the work / school account (aka organisational account).

If we use the work / school account and display the claim, we see:

If we use the MSA account, we see:

so there are some minor differences.

Also of interest is the fact that although WS-Fed was used in the flow we are getting an OAuth JWT not a WS-Fed SAML token.

After we have logged in as both, the login screen looks like:

So both are "signed in" but you can only pick one at any one time.

When I sign in to the work or school account, we see:

GET https://login.microsoftonline.com/common/oauth2/v2.0/authorize?

client_id=ce...3c

&redirect_uri=https%3a%2f%2flocalhost%3a44326%2f

&response_mode=form_post

&response_type=code+id_token

&scope=openid+email+profile+offline_access+offline_access

&state=OpenIdConnect.AuthenticationProperties%3dxK...Zi HTTP/1.1

which is OAuth (but note the V2 endpoint oauth2/v2.0/authorize)

This is followed by:

GET https://login.live.com/Me.srf?wa=wsignin1.0&idpflag=direct

&wreply=https%3A%2F%2Flogin.microsoftonline.com HTTP/1.1

which is WS-Fed

Not sure why both are invoked?

Early days - no doubt more documentation will be forthcoming.

Enjoy!

Identity : The Microsoft landscape

I get asked a lot about this.

• What is the stack?
• What are the pieces?
• How do they fit together?

There doesn’t seem to be a short, compact overview about this.

So in the spirit of the Github admin who when I ask “Is this feature available and if not when”? replies “Send me a PR”, here goes:

A very short summary – you could write a book on each :-)

In no particular order:

AD DC

Active Directory Domain Controller

The heart of Microsoft on-premises Identity.

It stores users, groups, group policy, printers etc.

Authentication is via Kerberos or NTLM.

In the same domain, IWA can be used if the browser is configured correctly.

AD LDS

Active Directory Lightweight Directory Server - aka ADAM.

Provides ability to store application specific attributes.

Can have many instances on a server, each with a different schema.

Not domain centric.

With ADFS 4.0 (Server 2016) can be used for authentication - ADFS : Authenticating with LDAP.

ADFS

Active Directory Federation Services.

On-premises.

Sits on top of AD. 

Provides WS-Fed / SAML 2.0 / OAuth2 (Server 2016) federation functionality.

Authentication is via WS-Fed or SAML 2 or OAuth.

Has claims rules to manipulate the claims. 

ADFS 4.0 (Server 2016) will support OpenID Connect and OAuth 2.0.

ADFS 4.0 (Server 2016) will authenticate against v3 LDAP or SQL Server.

Has DRS capability to allow devices to be “domain joined”.

Supports IWA.

Can federate with other IDP e.g. OpenAM, Ping Federate, shibboleth, simpleSAMLphp etc.

ADFS 2.0 was a separate download. From then on is a server role and part of the base server.

WAP

Web Application Proxy.

On-premises.

A proxy for ADFS.

Allows ADFS to sit behind a firewall.

Functionality is being added to make it closer to what TMG provided.

Azure AD

Azure Active Directory.

NOT AD in the cloud.

You can think of it as combining AD and ADFS functionality.

Graph based (not LDAP). Supports users and groups only.

Windows 10 devices can be added via “AD Join”.

Has three levels viz. Free / Basic / Premium. Comparison here  – Azure Active Directory editions

Claims collection is hard-coded.

Has outbound SCIM support.

Azure AD Connect

Utility to sync. configured AD attributes from AD to Azure AD. 

This provides Same Sign On. Adding ADFS provides Single Sign On.

Was previously called DirSync.

Azure AD Application Proxy

WAP in the cloud.

Azure AD Domain Services

AD DC in the cloud.

Authentication is via Kerberos or NTLM.

Azure B2C

Business to Consumer.

Allows external user management - registration, SSPR, social logins

Azure B2B

Business to Business

Automated way to provision users so they can authenticate across tenants.

B2B vs. B2C - Comparing capabilities for managing external identities using Azure Active Directory.

Azure Access Panel

Allows end-users to launch their apps and access the self-service features that allow them to manage their apps and group memberships.  

ACS

Access Control Service

The "old" way to connect to social logins - superseded by B2C.

Azure MFA

Multi Factor Authentication.

Easily integrated with Azure applications or on-premises via agent in conjunction with ADFS.

Azure AD Connect Health

Helps monitor and gain insight into on-premises identity infrastructure and the synchronization services.

Monitoring capabilities for key identity components e.g. ADFS, Azure AD Connect, AD DC etc.

Makes the key data points about these components easily accessible, making it easy to get usage and other important insights.

Azure AD Identity Protection 

Helps prevent the use of compromised accounts using industry leading machine learning (ML) based real time detection and automated mitigation.

Helps protect all of the cloud and on-premises applications customers use with Azure AD.

Can auto-remediate by intercepting the request with an adaptive MFA challenge such as an SMS, phone call, push notification or a request for OATH token.

Azure AD PIM

Privileged Identity Management.

Discovery and control of who has administration rights where and when.

Microsoft Advanced Threat Analytics

Detects suspicious user and entry activity, known malicious attacks and security issues.

Cloud App Discovery

Helps IT departments learn which SaaS apps are being used throughout the organization.

Can measure app usage and popularity so that IT can determine which apps will benefit the most from being brought under IT control and being integrated with Azure AD.

Azure SaaS Market Place 

Aka Gallery - Active Directory Marketplace.

Instantly configure popular SaaS cloud applications on Azure AD for SSO and easier user account management.

Wrappers

WIF / OWIN / ADAL : Identity Libraries: Status

Also WIF : Wrappers around protocols  

And OWIN : Differences with WIF

WIF

Windows Identity Foundation.

Provides WS-Fed client protocol support for .NET applications.

Can be passive (browser) or active (WCF).

Older technology.

Capability provided by web.config configuration.

WIF 1.0 (3.5) is a separate download. WIF 4.5 is part of the framework.

OWIN

Open Web Interface for .NET.

Replaces WIF.

Provides WS-Fed / SAML 2.0  / OpenID Connect / OAuth 2.0 client protocol support for .NET applications.

NuGet packages here:

• Microsoft.Owin.Security.WsFederation  
• Microsoft.Owin.Security.OpenIdConnect 
• Kentor.AuthServices.Owin

Capability provided by code.

Can be used for web applications or web API.

.NET Core 1.0 support for OpenID Connect / OAuth 2.0.

Aimed at Azure AD / ADFS with hybrid mode – not a general purpose stack.

ADAL

Active Directory Authentication Library.

OpenID Connect / OAuth 2.0 client protocol support for native devices.

API so underlying protocol could be changed at some future point.

Libraries for JavaScript, Java, PHP etc.

Capability provided by code.

Aimed at Azure AD / ADFS with hybrid mode – not a general purpose stack.

MSAL

Microsoft  Authentication Library - V2 API.

Unified library that helps to develop applications that work with Microsoft Accounts, Azure AD accounts and Azure AD B2C users indifferently – all in a single, streamlined programming model.

Targets the "converged model" i.e. Microsoft Accounts and "Work or School" Accounts combined.

"Successor" to ADAL with the important proviso that it will not work with ADFS and the original Azure AD V1 API.

Microsoft Graph

Was Office 365 Unified API / Graph API.

Exposes multiple APIs from Microsoft cloud services through a single REST API endpoint (https://graph.microsoft.com).

MIM

Microsoft Identity Manager.

Used to be FIM.

Synchronizes identities between directories, databases and applications.

Self-service password, group and certificate management.

Enjoy!

AAD : Some protocol conversion

If you've ever looked at Auth0, you'll know that it's basically a circle that handles all the protocols and conversions and all applications and IDP's have one connection to the circle. Anyone can connect to anything.

You can come in with OpenID Connect and a JWT token and exit with SAMLp and a SAML token.

The same kind of thing happens with Azure AD where you have a federated tenant using ADFS for the authentication.

The user accesses a .NET application that uses the OWIN OpenID Connect stack to connect to AAD.

Something like:

GET https://login.microsoftonline.com/866...c0/oauth2/authorize

?client_id=98e...a73b006

&redirect_uri=https%3a%2f%2myapp.com%2f

&response_mode=form_post

&response_type=code+id_token

&scope=openid+profile

&state=OpenIdConnect.AuthenticationProperties%3dx...XbjvpmEy

&domain_hint=company.com

If you are wondering about the "domain_hint" see here: Using Azure AD to land users on their custom login page from within your app

AAD sees that this is a federated tenant and hands off to ADFS. The default for the Microsoft stack is WS-Fed.

Something like:

GET https://my-adfs/adfs/ls/?username=&wa=wsignin1.0&wtrealm=urn%3acompany

&wctx=abc...C7_3-B_AU1 

So AAD has done a protocol conversion from OpenID Connect / OAuth (oauth2/authorize) to  WS-Fed (wa=wsignin1.0).

Enjoy!

AAD : Azure AD and IDPInitiated

Came across this very interesting post in SO.

Custom SSO With Azure Active Directory.

Note the IDPInitiated section:

"Finally, if your application expects IdP initiated SSO, construct a canned SAML AuthNRequest and save it in a URL - when your organization's users will click on this URL (canned SAML AuthNRequest) - they will get redirected to Azure AD where they will sign-in and then the token will be posted to the application's AssertionConsumerServiceURL - resulting in the user getting signed in. 

You can use the following tool to create a SAML AuthNRequest":

https://www.authnauthz.com/SAML/OutboundAuthNRequest

Azure AD doesn't have an IDP Initiated endpoint so this is a neat little trick!

Enjoy!

AAD : The default WS-Federation claims

I have an ASP.NET RP using OWIN WS-Fed to talk to an ADFS instance and this ADFS instance has Azure AD as a CP.

For reference, this is the default claims set from AAD:

Claims from ClaimsIdentity

Claim Type	Claim Value
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier	QY7TN_h.....vFbw9IKD-nY
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress	joe.bloggs@company.com
http://schemas.microsoft.com/identity/claims/tenantid	4ef13bb.....a8291aeded
http://schemas.microsoft.com/identity/claims/objectidentifier	8f803ba.........63-eacba54
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name	joe.bloggs@company.com
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname	joe
http://schemas.microsoft.com/identity/claims/displayname	joe bloggs
http://schemas.microsoft.com/identity/claims/identityprovider	https://sts.windows.net/4e.....df-ad5a8d/
http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent	Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0
http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path	/adfs/ls/
http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork	true
http://schemas.microsoft.com/2012/01/requestcontext/claims/client-request-id	0000.....0-0080e7
http://schemas.microsoft.com/2012/01/requestcontext/claims/relyingpartytrustid	https://my-pc/WebApp-ADFS-DotNet/
http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-ip	111.11.111.111
http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod	http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password
http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant	2015-12-13T19:12:58.920Z

Sadly, there is no way currently to alter this default set other than to use Microsoft Graph to get the claims yourself.

Note that because AAD is built on a Graph platform, a lot of the values are actually GUID's.

Enjoy!