I was trying to set up an enterprise connection in Auth0 to my ADFS instance.
When I tried the "Test" button on the enterprise connection, I got:
"description": "the connection was disabled"
WTF?
Eventually I realised that this is because I do not have a client that is configured under "Connections" to use that enterprise connection.
Assigned this to a client and viola! all is well.
That error message needs improvement!
Enjoy!
Friday, September 29, 2017
Monday, September 25, 2017
ADFS : Pre-populating the user on the login screen
This question often comes up and I came across a site that does this.
Note this is with ADFS 4.0 (Server 2016).
The URL is:
GET https://my-adfs.cloudapp.net/adfs/ls/?login_hint=myuser%40dev.local
&wctx=Yue...BfN-A7v
&wtrealm=some_realm
&wa=wsignin1.0
...
etc
The ADFS login screen then looks like:
Enjoy!
Note this is with ADFS 4.0 (Server 2016).
The URL is:
GET https://my-adfs.cloudapp.net/adfs/ls/?login_hint=myuser%40dev.local
&wctx=Yue...BfN-A7v
&wtrealm=some_realm
&wa=wsignin1.0
...
etc
The ADFS login screen then looks like:
Enjoy!
Wednesday, September 13, 2017
ADFS : RP default token lifetime
This question keeps coming up.
The default value for TokenLifetime on a RP trust is 0. But what value is 0?
As usual, a heap of garbage via Google.
60 minutes, 300 minutes, 600 minutes, 10 hours ...
Using ADFS 4.0 and looking at a SAML RP, we get:
Conditions NotBefore="2017-09-12T19:24:01.817Z"
NotOnOrAfter="2017-09-12T20:24:01.817Z"
So the correct answer is 1 hour = 60 minutes.
Note: Don't confuse this with the ADFS wide WebSSOLifetime. This is a server wide timeout parameter.
The default value for that = 8 hours = 480 minutes.
Enjoy!
The default value for TokenLifetime on a RP trust is 0. But what value is 0?
As usual, a heap of garbage via Google.
60 minutes, 300 minutes, 600 minutes, 10 hours ...
Using ADFS 4.0 and looking at a SAML RP, we get:
Conditions NotBefore="2017-09-12T19:24:01.817Z"
NotOnOrAfter="2017-09-12T20:24:01.817Z"
So the correct answer is 1 hour = 60 minutes.
Note: Don't confuse this with the ADFS wide WebSSOLifetime. This is a server wide timeout parameter.
The default value for that = 8 hours = 480 minutes.
Enjoy!
Friday, September 01, 2017
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:
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!
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
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 : Using B2C as an Identity router
B2C has been touted as the successor to ACS but I've always struggled to understand this.
With the advent of custom policies, this is now doable.
Essentially, forget about using B2C as it's supposed to be used i.e. external customer registration and self service password reset.
Just use it as a hub / identity router.
You can configure a policy e.g. sign up / sign in to handle any number of IDP as long as they support OpenID Connect or SAML 2.0. Each of these is configured via XML in the custom policies. Each has a login button on the landing page.
You could almost think of B2C as acting as a pseudo Home Realm Discovery page.
B2C can be branded so it could have the same look and feel as the rest of the corporate pages.
e.g. this is my PoC page.
It allows you to sign up with Facebook, ADFS or Azure AD.
Downstream B2C only allows OpenID Connect so the path would be e.g.
Application --> OIDC --> B2C --> OIDC --> Facebook
--> SAML --> ADFS
--> OIDC --> AAD
Or if you wanted lots of social providers, you could go OIDC to something like Auth0 and then use their large array of social providers.
So it's pretty much ACS++!
WS-Fed support is on the way.
Enjoy!
With the advent of custom policies, this is now doable.
Essentially, forget about using B2C as it's supposed to be used i.e. external customer registration and self service password reset.
Just use it as a hub / identity router.
You can configure a policy e.g. sign up / sign in to handle any number of IDP as long as they support OpenID Connect or SAML 2.0. Each of these is configured via XML in the custom policies. Each has a login button on the landing page.
You could almost think of B2C as acting as a pseudo Home Realm Discovery page.
B2C can be branded so it could have the same look and feel as the rest of the corporate pages.
e.g. this is my PoC page.
It allows you to sign up with Facebook, ADFS or Azure AD.
Downstream B2C only allows OpenID Connect so the path would be e.g.
Application --> OIDC --> B2C --> OIDC --> Facebook
--> SAML --> ADFS
--> OIDC --> AAD
Or if you wanted lots of social providers, you could go OIDC to something like Auth0 and then use their large array of social providers.
So it's pretty much ACS++!
WS-Fed support is on the way.
Enjoy!
Subscribe to:
Posts (Atom)