Tuesday, June 14, 2016

Azure B2C : Integrating with Azure "Easy Auth"

I've done a series of posts around integrating applications with Azure AD B2C.

The theme to all of them is that B2C extends OAuth by adding the profiles to the request.

There's an example of this in the sample.

Another solution is to bridge "normal" OAuth and this extension with something like IdentityServer as described here.

And then I came across this article - App Service Auth and Azure AD B2C.

If your application is a web application in Azure (i.e. an app service), you can now integrate with B2C as per the article by using "easy auth".

What this means is that you can add the extended support via a few mouse clicks.

The end result is that your application can now connect directly to B2C without a bridge.

Powerful stuff!

There are a few gotchas as mentioned in the article.

You do not need an Azure subscription to create a B2C directory. However, you do need one to create an app. service that is required to get this to work.

So create another subscription and then map this to the B2C directory.

You can do this in the old Azure portal:


Another gotcha is that when you login to the new Azure portal, you may be in the wrong directory and get all sorts of access denied / rights issues.

You can make sure that you are in the B2C directory by clicking on your login name (top right) and then selecting the B2C directory in the "Directory" section in the drop down.

The third gotcha is to note this sentence "Note that in step 2, you’ll need to use the https address of the web app". If you just use the http address, you get a "URL must be in same domain" error.

Once authenticated, a quick way to see what claims you have is to to look in the trace.

Looking at the token in jwt.io, I see:


Now if you go to the web application and add "/.auth/me" to the URL i.e. something like:

https://xxx.azurewebsites.net/.auth/me

you get the JSON token:

etc.

Footnote:

If you take all the social logins that are possible, you start off in IdentityServer with:

Facebook, Google and Twitter

Working up the chain, Easy auth adds:

MSA, Facebook, Google, and Twitter

B2C adds:

MSA, Facebook, Google, LinkedIn, and Amazon

which could all end up in complete confusion :-)

Enjoy!

ADFS : All good things come to an end

One upon a time way back in 2008, Microsoft came up with a new direction for authentication and authorisation called "Claims-based authentication".

They had a new STS (that became ADFS) that had the codename "Geneva" and a new set of client-side classes to handle the WS-Fed interaction with Geneva called WIF.

It was announced in a blog post on November 3rd 2008.

And Vittorio Bertocci came on board as an evangelist to help spread the word.

To handle all the inevitable teething problems they created a forum. This was mainly focused on development.

The world rolls on, claims are now mainstream and underpin the Microsoft stack e.g. Office 365, Azure AD, SharePoint, CRM Dynamics etc.

WIF rolled through to OWIN (Katana) and OWIN is rolling through to IdentityServer in .NET Core.

ADFS 2.0 will shortly become ADFS 4.0 with far more functionality.

The ADFS proxy became WAP.

Vittorio is now a Principal PM with the Azure AD team.

And so this forum has closed.

Which is sad in a way. Looking back through my history, I first started answering questions in June 2011 - five long years ago.

Since then, I've contributed to almost 700 questions and hopefully helped a lot of people trying to get to grips with these products.

The content is still fully searchable so all that goodness lives on.

The good news is the forum lives on in a more focused way.

Hope to see you there!

Enjoy!

Thursday, June 09, 2016

Azure B2C : FAQ

There is a lot of confusion around Azure Active Directory (AD) B2C as to where it sits so I thought I would do a FAQ around the questions I've been asked.

I will update this as new questions come in or feel free ask away in the comments.

Overview here.

Official Azure AD B2C FAQ here.

Q: How do I add a SaaS application to B2C?

A: B2C only supports Open ID Connect. It needs some OAuth tweaks to add in profile details. If the SaaS application can make those changes, then yes. If not, you need a bridge (see link). To support WS-Fed and SAML 2.0 you need a bridge as described here. (But note "easy auth" link below).

Q: I see that you used IdentityServer as a bridge. Is that the only solution?

A: No - you could use something like Auth0 as well. The key is that it has to be customisable and it has to be able to support both CP and RP.

Q: ADFS v4.0 (Server 2016) supports OIDC. Could I use this as a bridge?

A: No - ADFS v4.0 is not customisable and it only supports OIDC as a RP not as a CP.

Q: How can I do SSO with ADFS and B2C?

A: At the moment you can't. As above there is no way to connect them directly. However, you could try something like:

Application --> WS-Fed / SAML / OIDC --> ADFS --> WS-Fed / SAML --> IdentityServer --> OIDC --> B2C.

Q: Azure B2C runs on Azure AD. I can set up a federated tenant with ADFS and Azure AD. So why can't I do this with B2C?

A: B2C is a "different kind" of Azure AD tenant. It was developed for a use case of millions of external users that have no need for SaaS or federation.

Q: Can I use AAD Connect to provision my users in B2C?

A: No - that only works for "normal" Azure AD. In addition,  AAD Connect provisions users from AD. Typically, these are internal users inside a company's intranet. B2C supports a different use case - external users not directly employed by a company and on the internet. So it wouldn't make sense to use AAD Connect.

Q: So I can't programmatically provision my users in B2C?

A:  Yes you can via the Graph API. Have a look at the sample.

Q: Does B2C allow SSO across applications?

A: All applications that can authenticate with B2C have SSO across them.

Q: What about logout from B2C?

A: That's more a function of OIDC and currently there is no standardised logout functionality.

Q: Can I use the NuGet Microsoft OWIN OIDC package to connect to B2C?

A: No not OOTB - B2C uses profiles and these profiles have to be added to the OAuth message. Refer B2C sample code.

Q: So I can't use any standard OIDC library?

A: Not OOTB - they require customisation.

Q: My application is already hosted in Azure as an app. service. Can I integrate that?

A: Yes - refer to this "easy auth" link.

Q. What about other languages e.g Java?

A: I have heard of people using a Java OIDC library that they customised.

Q: I already have an Azure AD tenant. Can I use that for B2C?

A:  No - B2C is a "different kind" of Azure AD tenant. When you create a new Azure AD tenant, you'll see there is a check-box that asks you if this is for B2C. The Azure AD tenant is either "normal" or B2C - it can't be both.

Q: I have a number of different logons on B2C - local and some social. However, they are all for the same person i.e. me. Is there any way to link all these identities?

A: No - not at the moment.

Q: Can I add other social providers?

A: No - not at the moment.

Enjoy!

Azure B2C : Integration with IdentityServer

This post covered an overview of Azure Active Directory (AD) B2C and described some of the gotchas.

Imagine you have purchased a SaaS application that supports "normal" OpenID Connect. The vendor has quoted a ridiculous price to add the profile support necessary for the SaaS application to connect to Azure B2C.

One way around this (as you guessed from the title!)  is to add IdentityServer into the mix.

The path would then be:

SaaS application --> normal OIDC --> IdentityServer --> add profile info. to OIDC --> Azure B2C

The Azure AD B2C sample is Azure AD B2C preview: Build a .NET web app.

We need to add Azure B2C to IdentityServer as an external OIDC CP.

The SaaS application is added to IdentityServer as an OIDC RP.

For simplicity, just sign-in is covered. I'm assuming the user has already registered themselves.

As usual, here is the gist.

(Note that this is still a work in progress. Some B2C claims are not being passed through. I'm still investigating that. Hopefully, this does provide some guidance).

To test this out, I used this sample as the SaaS application. This uses "normal OIDC" to talk to IdentityServer.

The B2C sign-in profile is configured to allow local account login plus Facebook.

When the user clicks Sign-In in the application. they see this IdentityServer HRD screen.


The user selects "Azure B2C".

They then get redirected to B2C and:


They select "Local Account SignIn" and enter their credentials.

They are then redirected back to the application and see their claims.


To expand this into "SignUp", "Edit Details", "Reset Password" etc. you could have some more buttons on the HRD screen each tied into a different B2C profile.

However, this assumes that all applications will have the same set of authentication providers. For the case where some applications use Facebook only, some use local and Twitter etc. there will have to be some kind of mapping table mapping applications to providers.

And some of you will be asking "What about SaaS applications that use WS-Fed or SAML?". Good question, that was another reason to add IdentityServer into the mix and that is the subject of another post.

Enjoy!

OpenID Connect: Displaying the JWT

Just a quick post as I have had a number of questions around this recently.

If you are tracing an OpenID Connect connection e.g. to ADFS v4.0 or Azure AD, it is often useful to see what is in the JWT.

I use SAML tracer on Firefox. You can use this to trace anything not just SAML!

After authentication, look at the trace.


Here is the HTTP POST to my test application. Note the two tabs.


Now selecting the Parameter tab shows the id_token.

Copy and paste the Base64 string into https:jwt.io .


Paste into this box and you will see the decoded token.

Enjoy!

Wednesday, June 08, 2016

Azure B2C : An overview

This is a lead-in to future posts!

Azure Active Directory (AD) B2C (Business to Consumer) covers the use case where a company has internal users that use Office 365, Azure AD, some SaaS packages etc.

At the same time, they want to interact with external users but they don't want the details in the "internal" repository and they don't want hundreds of phone calls to the help desk about expired passwords etc.

They want the users to self-register and they want to be able to mine the user's details.

This is what B2C provides - a repository for external users only with self-registration and self-service password reset.

So you could imagine a company portal that allows users to browse the company products, read information about new products, register an interest in some future product etc.

This portal is then configured in B2C as an application (in the same way that you configure applications in Azure AD).

When the external user navigates to the application, they can choose to:
  • Sign-up
  • Sign-in
  • Update details
  • Reset their password
When the user signs-up, they are asked for a set of configurable details e.g. first name, last name, email etc. These details are then written to an Azure AD B2C repository.

When the user signs-in, they are redirected to B2C for authentication. They can log into the B2C repository or they can use some social logins. These all use OpenID Connect and then a JWT token is returned with the user's claims.

Sign-up, sign-in etc. all use policies. These are all configured in the Azure AD portal. You can have any number of these policies. An application specifies the policies it wants to use.

An example of a sign-up policy is to capture:
  • First name
  • Last name
  • Email
  • Address
  • Postal code 
  • Phone number
There are a number of built-in attributes (like email). You can also configure custom attributes.

Note that the email address is not of the form joe.bloggs@onmicrosoft.com. It can be e.g. joe.bloggs@gmail.com.

An example of a sign-in policy is to allow:
  • Local
  • Facebook
  • LinkedIn
B2C can scale to millions of users.

B2C also supports the Graph API so user CRUD etc. can be done programmatically.

More B2C information.

The downside is that:
  • These users cannot interact with any SaaS offering e.g. they cannot have Office 365 licences
  • They are in a separate Azure AD repository so they can't interact with users in a "normal" repository
  • Only OpenID Connect is supported
  • The policies need to be sent in the OAuth messages so this is not "normal" OAuth
Ways around these problems will be addressed on the next few posts.

Enjoy!

Monday, May 16, 2016

Misc : "Why I Haven’t Fixed Your Issue Yet"

This really resonated with me.

Why I Haven’t Fixed Your Issue Yet

I don't do that much open source work - a bit - but nowhere near as much as I help out on Forums.

I help out on forums because I like to pay something back but it's not my full-time job and I don't get paid for it :-)

I get that you have a critical deadline, that your boss is on your back, that you are close to panic etc. but you are not the only one in the forums and like the writer above, I have to prioritise.

I give preference to those people who have actually tried to solve the problem e.g. they paste the ADFS claims rules that don't work.

People who write "HELP NEEDED" or "CRITICAL" and then leave a description like "Doesn't work" and I need three "answers" to tease out what version they are using against what repository and essentially expect me to do their job for them tend to be at the bottom.

And answers like "Don't have time to understand regex" pretty much guarantee that they will be back next week with another variation of the same problem.

Yes - it's hard but is it not part of your job to understand this stuff?

There are no excuses - there are hundreds of articles, books, Pluralsight etc.
'
Have a read of Jon Skeet's classic Writing the perfect question.

Help me to help you by describing and documenting the problem.

Oh and by the way, it's considered good etiquette to mark the question as answered, give reputation points or whatever if I help solve the problem.

Enjoy!

Friday, May 13, 2016

Azure B2C : Differences with Access Control Services (ACS)

B2C is the way forward for ACS.

Refer : The future of Azure ACS is Azure Active Directory.

I put this table together:



Note 1: Azure B2C : Differences with Azure Active Directory (AAD)

Any E&O, fell free to discuss via comments. 

Enjoy!

Thursday, May 12, 2016

Azure B2C : Differences with Azure Active Directory (AAD)

There are a number of gotcha's with B2C that you may not realise at first.

This is still in preview so things will undoubtedly change and there is also B2C Premium on the horizon but no details are publicly available.

More details around limitations here.

To be fair, B2C is aimed at a completely different use case viz. external users who can self-manage via self-service registration and who need SSPR functionality.

I put this table together:


Azure AD
Azure B2C


Can share tenant e.g. with O365
B2C separate tenant that can contain B2C users only


Can add SaaS applications via Market Place
N/A


Can federate with other IDP
N/A


AD sync. via AD Connect
N/A


Users can have O365 licences
N/A


Support for WS-Fed, SAML 2.0p, OpenID Connect, OAuth2
Some OpenID Connect, OAuth2 functionality
(See below)


Support for Single Page Application (SPA) front-end that is written primarily in JavaScript and often uses a SPA framework such as AngularJS, Ember.js, Durandal, etc.
N/A


Web API support for OAuth 2.0 JWT Bearer Credential Grant, otherwise known as the On-Behalf-Of flow
N/A


Support for OAuth 2.0 client credentials flow
N/A – must use OpenID Connect to authenticate first


Wide range of authentication platforms
Only .NET, iOS, Android, and NodeJS


Social support for Yahoo, Facebook, Google and MSA (Windows Live) via ACS
Social support for Facebook, Google, Amazon, LinkedIn and MSA (Windows Live)


Can add additional social providers via Identity aaS e.g. Auth0, Optimal IDM etc.
N/A


Can verify custom domains
N/A on classic portal

Any E&O, fell free to discuss via comments.

Enjoy!

Wednesday, May 04, 2016

ADFS : Expired password

Continuing from ADFS : Adding "Change Password" to the default login page.

This concerned "Change Password" but then I came across a reference to the effect that once this feature was enabled, it also handled "Expired Password".

Now I tried this on Active Directory Federation Services on Server 2016 Technical Preview 4 (ADFS 4.0) but the article states that it works on ADFS 3.0 (Server 2012 R2) as well.

After logging in with an expired password. I got:


Very neat!

However, for "Forgotten Password" i.e. user requires a "Reset Password", you are out of luck.

You could configure one of the configurable strings using PowerShell to say something like "Forgot your password?" and then link that to a custom web site that you would have to create that talks to AD via LDAP.

Obviously there are security constraints with this e.g. you need something like "Secret Q & A".

Enjoy!

Monday, May 02, 2016

ADFS : Server 2016 OAuth JWT is missing scope and NameID

This is for Active Directory Federation Services on Server 2016 Technical Preview 4 / 5.

As per ADFS : Daemon and Web API on Server 2016 TP4 ADFS 4.0, I made the comment:

"The Azure AD sample relies on scope and NameID claims being returned in the JWT token. This is OK in Azure AD where the claims are static and Azure ID knows the ID of the application which is returned as a GUID in the NameID claim. ADFS AFAIK does not have claims rules for this so I hard coded the NameID. Hopefully, this will be resolved as more documentation is forthcoming."

Then I came across AD FS On-behalf-of Authentication in Windows Server 2016.

As per that article, you have to manually generate the scope claims!

They use the following claims rules:
@RuleName = "All claims"
c:[]
=> issue(claim = c);

@RuleName = "Issue open id scope"
=> issue(Type = "http://schemas.microsoft.com/identity/claims/scope", 
Value = "openid");

@RuleName = "Issue user_impersonation scope"
=> issue(Type = "http://schemas.microsoft.com/identity/claims/scope", 
Value = "user_impersonation");
These match the scope check boxes configured in ADFS in the application group.

This means that every time you alter the scopes you need to alter the claims rules.

Hopefully, this will be fixed before the official release.

The other issue I had was with NameID.

As per that article:

"From AD FS we are issuing the Nmae claim but we are not issuing NameIdentifier claim. The sample uses NameIdentifier to uniquely key in the ToDo items. For simplicity, you can safely remove the NameIdentifier with Name claim in the code. Find and replace all occurences of NameIdentifier wiht Name."

(Spelling as per original article.)

My solution was simply to generate a static NameID. The whole point is to have a unique key into the token store.

Enjoy!

ADFS : OpenID Connect and OAuth2 support on Server 2016 TP5

This is for Active Directory Federation Services on Server 2016 Technical Preview 5.

This is the last TP before RTM.

I've done a series of posts on this capability in TP4 and I tried a few of the use cases in TP5 and they worked no problem.

All you need to do is to change the metadata URL and the clientID and the secret key.

So much easier when you have a working sample as reference :-).

There is a similar series of Microsoft posts here. I believe that more content is going to be added prior to RTM.

The format of these posts is somewhat different to the way that I do them but I will leave you to decide which way you prefer!

Enjoy!