ADFS : Authentication with .NET Core

This is for Active Directory Federation Services (ADFS / "AD FS") on Server 2016 Technical Preview 5.

The client is built on .NET Core along the lines of AAD : Authentication with .NET Core.

So I built the .NET Core sample as per the post above and then changed the code as per this gist.

I configured ADFS by adding an application group and picking "Standalone Application" and "Server application or Website".

Then:

The Client ID needs to be cut and pasted into appsettings.json as does the secret key that you generate as part of the process.

Note that you have to add "/signin-oidc" to the Redirect URL. I have no idea where this comes from. It must be added somewhere as part of the middleware.

Then I got this error:

Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthClientCredentialAuthenticationException: MSIS9267: No Client credentials found in the request. Client '2c...b7' is configured as a confidential client.

Zero documentation on this and much frustration but then in desperation I added the ClientSecret in the code and suddenly it worked!

I did not do this when I did the other examples e.g. ADFS - Web App and Web API on Server 2016 TP4 ADFS 4.0 and they worked so completely baffled!

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!

ADFS : Capacity Planning

This is for Active Directory Federation Services (ADFS / AD FS).

There used to be a useful capacity planning spreadsheet available which disappeared for a while.

It's now back and there's one for Server 2016 (ADFS 4.0) as well .

AD FS Capacity Planning Spreadsheet

AD FS Windows Server 2016 Capacity Planning

Enjoy!

Speaking : Getting organised

I been doing a few presentations lately and doing some co-presenting. Some of this with people with very little speaking experience.

Two tips:

Have a work sheet

Write down all the screens and utilities that you will use and use this to check that all are open and logged in before the presentation starts.

e.g.

• I'm using Azure so ensure I'm logged into the classic and new portal.
• I'm using Zoomit so ensure it's opened
• I'm using VS so ensure it's opened and the correct project is loaded
• I'm using Notepad++ so ensure it's opened

The audience doesn't want to watch you logging into Azure or trying to find that icon.

Write down what you will demo.

When you are standing up there you will be nervous and you will forget to demo. some stuff.

So write down what you will demo., the order, any pertinent points etc.

Print this out in larger type so you can read it from some distance. Have blank lines between the points.

Good luck.

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!

Azure B2C : B2C user types

There are a number of ways that you can add a user to Azure Active Directory (AAD) B2C (Business to Consumer).

If you look at the "Users sourced from" column, you'll see:

• Microsoft Azure Active Directory
• Microsoft Azure AD (other directory)
• Microsoft account

"New user in your organization"

Your B2C tenant has a name - something like b2c.onmicrosoft.com.

So this user would have a name like joe.bloggs@b2c.onmicrosoft.com.

However, this type of user would be an admin. They couldn't actually log into B2C as an external user because to do this, they would have to have an email address for the confirmation email during sign-up.

Since B2C users cannot have Office 365 accounts this is not possible.

Basic rule of thumb: If you don't sign-up with B2C, you can't sign-in to an application with B2C.

Another way of looking at this is that there are two use cases:

• Signing into the B2C tenant - manage.windowsazure.com (for admin. purposes)
• Signing into an application secured by B2C (to access the application)

 We can look at the user's details using Graph Explorer.

(Plus the contents of the claim).

This type of user would have:

"creationType": null

"mailNickname": "user2"
     
"userPrincipalName": "user2@b2c.onmicrosoft.com"

"User with an existing Microsoft account"

This would be for admin. purposes only.

"User in another Microsoft Azure AD directory"

I've found that you need to have rights to the other directory to do this.

"creationType": "Invitation"

"mailNickname": "user_tenant.onmicrosoft.com#EXT#"

"userPrincipalName": "user_tenant.onmicrosoft.com#EXT#@b2c.onmicrosoft.com"

Again this would be an admin. type thing because when you authenticate you are doing this on another tenant, not on B2C.

"User in partner companies"

If you don't have rights, you can use Azure AD B2B. You import a .csv spreadsheet then each user gets an acceptance email with a link they have to click on.

This has the same sort of parameters as "user in another AD directory" but it has an extra section:

"proxyAddresses": [
        "smtp:user_tenant.onmicrosoft.com#EXT#@b2c.onmicrosoft.com",
        "SMTP:user@tenant.onmicrosoft.com"
      ]

Again this would be an admin. type thing because when you authenticate you are doing this on another tenant, not on B2C.

It's a bit confusing that you can add other users in this way as they can't actually authenticate as B2C users but I suppose this is for admin. purposes?

All the above are created by using the Azure portal.

A normal B2C user does not use this portal. They sign-up to B2C by using the sign-up link in the application e.g. as per Azure AD B2C preview: Build a .NET web app.

You can sign-up as a local user i.e. your credentials are stored in Azure AD in the B2C tenant or you can sign-up using social in which case some attributes are stored in the tenant but not the credentials.

e.g. local user

creationType": "NameCoexistence"

"mailNickname": "91...61"

"userPrincipalName": "91...61@b2cnz.onmicrosoft.com"

e.g. Facebook user

"creationType": null

"otherMails": [
        "Facebook email"
      ]

http://schemas.microsoft.com/identity/claims/identityprovider    facebook.com
     
"userPrincipalName": "cpim_37...a7@b2c.onmicrosoft.com"

These users can sign-in to an application secured by B2C.

A key point is that the local users have an external email e.g. joe.bloggs@hotmail.com whereas the admin. users typically have an email like joe.bloggs@tenant.onmicrosoft.com

Enjoy!