Utilities to help you develop using OpenID Connect and OAuth 2.0 are always useful so I've listed out the ones I know about.
Postman - Really useful to for API testing. Requires Chrome.
v2.0 Protocols - OAuth 2.0 Authorization Code Flow - Article that has links to Postman collection to try this out step by step. Azure AD centric.
Inspecting the JWT token - from Auth0.
Outlook OAuth Sandbox - for testing Outlook.Office.com API.
OpenID Connect Playground - from Auth0 - for developers to test and work with OpenID Connect calls.
Demo. instance of IdentityServer - has full stack OIDC / OAuth2 support.
Tying the two together - hooking the playground up with IdentityServer.
Enjoy!
Showing posts with label OpenID Connect. Show all posts
Showing posts with label OpenID Connect. Show all posts
Thursday, August 18, 2016
Thursday, June 09, 2016
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!
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!
Monday, May 02, 2016
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!
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!
Wednesday, April 13, 2016
ADFS : Authenticating with LDAP
This is for Active Directory Federation Services on Server 2016 Technical Preview 4.
Just to re-iterate - the ADFS has to be Server 2016 - TP4 and above. This will not work on Server 2012 R2 - ADFS 3.0.
I used the following for reference:
"AD FS supports any LDAP v3-compliant directory.
In order for AD FS to authenticate users from an LDAP directory, you must connect this LDAP directory to your AD FS farm by creating a local claims provider trust.
You can support multiple LDAP directories, each with its own configuration, within the same AD FS farm by adding multiple local claims provider trusts. In addition, AD DS forests that are not trusted by the forest that AD FS lives in can also be modelled as local claims provider trusts. You can create local claims provider trusts by using Windows PowerShell.
LDAP directories (local claims provider trusts) can co-exist with AD directories (claims provider trusts) on the same AD FS server, within the same AD FS farm, therefore, a single instance of AD FS is capable of authenticating and authorising access for users that are stored in both AD and non-AD directories.
Only forms-based authentication is supported for authenticating users from LDAP directories.
Certificate-based and Integrated Windows authentication are not supported for authenticating users in LDAP directories.
All passive authorisation protocols that are supported by AD FS, including SAML, WS-Federation, and OAuth are also supported for identities that are stored in LDAP directories.
The WS-Trust active authorisation protocol is also supported for identities that are stored in LDAP directories."
And:
"In ADFS v1.0 and ADFS v1.1 it was possible to use both AD and AD LDS / ADAM as an identity store. One of the very common scenarios is to use the AD identity store for internal users and use the AD LDS / ADAM identity store for external users (e.g. partners, customers, vendors, etc.).
All the ADFS versions starting with ADFS v2.0 and higher only supported AD as the identity store and nothing else. That could be one of the reasons why some companies remained using ADFS v1.x.
If you would like to support a similar scenario, where you would like to have a separate identity store for externals, you would need to either:
AD LDS is an instance of an LDAP and hence can be supported by ADFS 4.0. This means you can finally retire that instance of ADFS 1.x. Cue massive applause :-)
The previous post detailed how to run up an instance of AD LDS on Server 2016.
This all has to be done with PowerShell. The instance names are as per that previous post.
$DirectoryCred = Get-Credential
This pops up FBA. I used my domain admin. account.
$vendorDirectory = New-AdfsLdapServerConnection –HostName my-adfs.dev.local –Port 50000 –SslMode None –AuthenticationMethod Basic –Credential $DirectoryCred
$GivenName = New-AdfsLdapAttributeToClaimMapping –LdapAttribute givenName –ClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname”
$CommonName = New-AdfsLdapAttributeToClaimMapping –LdapAttribute cn –ClaimType “http://schemas.xmlsoap.org/claims/CommonName”
$Surname = New-AdfsLdapAttributeToClaimMapping –LdapAttribute sn –ClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname”
Add-AdfsLocalClaimsProviderTrust –Name "AD LDS" –Identifier "TP4-1" –Type Ldap -LdapServerConnection $vendorDirectory –UserObjectClass user –UserContainer "CN=ADFS,DC=dev,DC=local" –LdapAuthenticationMethod Basic –AnchorClaimLda
pAttribute mail –AnchorClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" –LdapAttributeToClaimMapping @($GivenName, $Surname, $CommonName) -AcceptanceTransformRules "@RuleName = `"Issue All Mapped Claims`"`nc:[] => is
sue(claim = c);" –Enabled $true
This will give a warning:
"WARNING: PS0245: Because no organizational account suffixes were specified, this claims provider trust will not be accessible by requests that use the active profile."
If you want this, you need:
Set-AdfsClaimsProviderTrust -TargetName "AD LDS" -OrganizationalAccountSuffix @("dev.local")
Note that the HRD screens will then be slightly different. You can see examples of this in the second article above.
When I setup the local CP trust, I got an error around invalid credentials. I eventually noticed that I had omitted to define $Surname. Once I fixed that, the error went away. That error is very misleading!
Also note that the new CP will not be displayed in the ADFS wizard.
You can, however, see it with:
(This makes sense when you remember that AD LDS is just the Identity repository. The actual protocol layer is handled by ADFS).
When we run up the sample, we see the expected HRD.
Authenticating with "adamuser1@dev.local" we get the expected JWT claims:
Goodbye ADFS 1.x!
Enjoy!
Just to re-iterate - the ADFS has to be Server 2016 - TP4 and above. This will not work on Server 2012 R2 - ADFS 3.0.
I used the following for reference:
- Configure AD FS to authenticate users stored in LDAP directories
- Configuring A New Identity Store As A Claims Provider In ADFS
"AD FS supports any LDAP v3-compliant directory.
In order for AD FS to authenticate users from an LDAP directory, you must connect this LDAP directory to your AD FS farm by creating a local claims provider trust.
You can support multiple LDAP directories, each with its own configuration, within the same AD FS farm by adding multiple local claims provider trusts. In addition, AD DS forests that are not trusted by the forest that AD FS lives in can also be modelled as local claims provider trusts. You can create local claims provider trusts by using Windows PowerShell.
LDAP directories (local claims provider trusts) can co-exist with AD directories (claims provider trusts) on the same AD FS server, within the same AD FS farm, therefore, a single instance of AD FS is capable of authenticating and authorising access for users that are stored in both AD and non-AD directories.
Only forms-based authentication is supported for authenticating users from LDAP directories.
Certificate-based and Integrated Windows authentication are not supported for authenticating users in LDAP directories.
All passive authorisation protocols that are supported by AD FS, including SAML, WS-Federation, and OAuth are also supported for identities that are stored in LDAP directories.
The WS-Trust active authorisation protocol is also supported for identities that are stored in LDAP directories."
And:
"In ADFS v1.0 and ADFS v1.1 it was possible to use both AD and AD LDS / ADAM as an identity store. One of the very common scenarios is to use the AD identity store for internal users and use the AD LDS / ADAM identity store for external users (e.g. partners, customers, vendors, etc.).
All the ADFS versions starting with ADFS v2.0 and higher only supported AD as the identity store and nothing else. That could be one of the reasons why some companies remained using ADFS v1.x.
If you would like to support a similar scenario, where you would like to have a separate identity store for externals, you would need to either:
- Configure a separate AD with its own ADFS infrastructure and configure federation between them
- Use Azure AD to store those identities and configure federation"
AD LDS is an instance of an LDAP and hence can be supported by ADFS 4.0. This means you can finally retire that instance of ADFS 1.x. Cue massive applause :-)
The previous post detailed how to run up an instance of AD LDS on Server 2016.
This all has to be done with PowerShell. The instance names are as per that previous post.
$DirectoryCred = Get-Credential
This pops up FBA. I used my domain admin. account.
$vendorDirectory = New-AdfsLdapServerConnection –HostName my-adfs.dev.local –Port 50000 –SslMode None –AuthenticationMethod Basic –Credential $DirectoryCred
$GivenName = New-AdfsLdapAttributeToClaimMapping –LdapAttribute givenName –ClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname”
$CommonName = New-AdfsLdapAttributeToClaimMapping –LdapAttribute cn –ClaimType “http://schemas.xmlsoap.org/claims/CommonName”
$Surname = New-AdfsLdapAttributeToClaimMapping –LdapAttribute sn –ClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname”
Add-AdfsLocalClaimsProviderTrust –Name "AD LDS" –Identifier "TP4-1" –Type Ldap -LdapServerConnection $vendorDirectory –UserObjectClass user –UserContainer "CN=ADFS,DC=dev,DC=local" –LdapAuthenticationMethod Basic –AnchorClaimLda
pAttribute mail –AnchorClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" –LdapAttributeToClaimMapping @($GivenName, $Surname, $CommonName) -AcceptanceTransformRules "@RuleName = `"Issue All Mapped Claims`"`nc:[] => is
sue(claim = c);" –Enabled $true
This will give a warning:
"WARNING: PS0245: Because no organizational account suffixes were specified, this claims provider trust will not be accessible by requests that use the active profile."
If you want this, you need:
Set-AdfsClaimsProviderTrust -TargetName "AD LDS" -OrganizationalAccountSuffix @("dev.local")
Note that the HRD screens will then be slightly different. You can see examples of this in the second article above.
When I setup the local CP trust, I got an error around invalid credentials. I eventually noticed that I had omitted to define $Surname. Once I fixed that, the error went away. That error is very misleading!
Also note that the new CP will not be displayed in the ADFS wizard.
You can, however, see it with:
Get-AdfsLocalClaimsProviderTrustTo test this I used the OpenID Connect sample referred to in one of my previous posts. Yes, you read that correctly. Not only are we going to authenticate on AD LDS with ADFS, we are going to use the OpenID Connect protocol. Neat!
UserObjectClass : user
UserContainer : CN=ADFS,DC=dev,DC=local
AnchorClaimLdapAttribute : mail
LdapAuthenticationMethod : Basic
LdapServerConnection : {my-adfs.dev.local}
LdapAttributeToClaimMapping : {Microsoft.IdentityServer.Management.Resources.LdapAttributeToClaimMapping, Microsoft.IdentityServer.Management.Resources.LdapAttributeToClaimMapping,
Microsoft.IdentityServer.Management.Resources.LdapAttributeToClaimMapping}
LocalClaimsProviderType : Ldap
AnchorClaimType : http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn
IdentifierType : http://schemas.microsoft.com/ws/2009/12/identityserver/principaltypes/uri
Identities : {http://schemas.microsoft.com/ws/2009/12/identityserver/TP4-1}
AcceptanceTransformRules : @RuleName = "Issue All Mapped Claims"
c:[]
=> issue(claim = c);
OrganizationalAccountSuffix : {}
Enabled : True
IsLocal : True
Identifier : TP4-1
Name : AD LDS
Notes :
ProtocolProfile : WsFed-SAML
(This makes sense when you remember that AD LDS is just the Identity repository. The actual protocol layer is handled by ADFS).
When we run up the sample, we see the expected HRD.
Authenticating with "adamuser1@dev.local" we get the expected JWT claims:
Goodbye ADFS 1.x!
Enjoy!
Tuesday, March 15, 2016
ADFS : OpenID Connect with Server 2016 TP4
There are some good articles around this:
OpenId Connect Web Sign On with ADFS in Windows Server 2016 TP3
Enabling OpenId Connect with AD FS 2016
Vittorio's article (the first one) is also good for configuring ADFS, setting up AD, promoting it as a DC etc.
I ran up the server as an Azure VM.
I used the second article.
Note that this is obviously copied and pasted from somewhere else because there are a number of errors:
I added more scopes so I had:
email, profile and openid
When you run up the sample, you may get an error along the lines of:
"The certificate is invalid according to the criteria".
To fix this, you have to add the ADFS SSL certificate to the client's trusted certificate store.
After successful authentication, using the Firefox SAML tracer, look at the response and you will see a parameter called "code" and another called "id_token".
The code is the access token which you can then use if e.g. you want to call a Web API.
The id_token is Base64 encoded and in JWT format so cut and paste it into Auth0's:
http://jwt.io
and you will see something like:
Header:
{
"typ": "JWT",
"alg": "RS256",
"x5t": "M7jHG4emiaI2_...50",
"kid": "M7jHG4emiaI2_...50"
}
Payload data:
{
"aud": "f93919a8-...142fdb",
"iss": "https://myadfs.TP4.cloudapp.net/adfs",
"iat": 1457987350,
"exp": 1457990950,
"auth_time": 1457987344,
"nonce": "635935841286452744.OTI0...DNkYzJi",
"sub": "US6dgINcoMI...Ehgw=",
"upn": "user-xxx@dev.local",
"unique_name": "DEV\\user-xxx",
"c_hash": "FlQfk4V_9...-xXw"
}
Now if you use the code from an earlier blog post to display the claims on the "Contact" page i.e.
ViewBag.ClaimsIdentity = Thread.CurrentPrincipal.Identity;
you'll see:
What's interesting is that you can't add claims rules in the ADFS wizard to a web site application group so e.g. the NameID is a GUID!
You'll notice the claims are a combination of OAuth and the old "WIF style".
Enjoy!
OpenId Connect Web Sign On with ADFS in Windows Server 2016 TP3
Enabling OpenId Connect with AD FS 2016
Vittorio's article (the first one) is also good for configuring ADFS, setting up AD, promoting it as a DC etc.
I ran up the server as an Azure VM.
I used the second article.
Note that this is obviously copied and pasted from somewhere else because there are a number of errors:
- You don't need an Azure subscription
- You don't need to do any Web API configuration
- You don't need the secret key, only the ClientID
I added more scopes so I had:
email, profile and openid
When you run up the sample, you may get an error along the lines of:
"The certificate is invalid according to the criteria".
To fix this, you have to add the ADFS SSL certificate to the client's trusted certificate store.
After successful authentication, using the Firefox SAML tracer, look at the response and you will see a parameter called "code" and another called "id_token".
The code is the access token which you can then use if e.g. you want to call a Web API.
The id_token is Base64 encoded and in JWT format so cut and paste it into Auth0's:
http://jwt.io
and you will see something like:
Header:
{
"typ": "JWT",
"alg": "RS256",
"x5t": "M7jHG4emiaI2_...50",
"kid": "M7jHG4emiaI2_...50"
}
Payload data:
{
"aud": "f93919a8-...142fdb",
"iss": "https://myadfs.TP4.cloudapp.net/adfs",
"iat": 1457987350,
"exp": 1457990950,
"auth_time": 1457987344,
"nonce": "635935841286452744.OTI0...DNkYzJi",
"sub": "US6dgINcoMI...Ehgw=",
"upn": "user-xxx@dev.local",
"unique_name": "DEV\\user-xxx",
"c_hash": "FlQfk4V_9...-xXw"
}
Now if you use the code from an earlier blog post to display the claims on the "Contact" page i.e.
ViewBag.ClaimsIdentity = Thread.CurrentPrincipal.Identity;
you'll see:
| Claim Type | Claim Value |
|---|---|
| aud | a29a6605-.0957 |
| iss | https://myadfs.TP4.cloudapp.net/adfs |
| iat | 1458089631 |
| exp | 1458093231 |
| http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant | 1458080168 |
| nonce | 6359368642...mMy |
| http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier | 3VYhqcs/b2H6n+4L4FXmlqX5A53+lnqqwq9Ectmg+3k= |
| http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn | userxxx@dev.local |
| http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name | DEV\userxxx |
| c_hash | YZH_zyOqt9...06Q |
What's interesting is that you can't add claims rules in the ADFS wizard to a web site application group so e.g. the NameID is a GUID!
You'll notice the claims are a combination of OAuth and the old "WIF style".
Enjoy!
Thursday, January 21, 2016
OAuth : Microsoft OWIN (for Identity) and ADAL are not general purpose libraries
I'm seeing a lot of confusion about this.
Microsoft has OWIN client libraries for OpenID Connect / OAuth2.
It also has ADAL - Active Directory Authentication Library (used mainly for native devices).
Both implement the protocols so you would think that you can use these to hook up to any server that implements OpenID Connect / OAuth.
Except that you would be wrong.
OAuth is notorious for incompatibility so you can't really mix and match.
These libraries are aimed at a specific use case i.e. the server is either Azure AD or ADFS.
In addition, the profile is hybrid flow so if your server doesn't implement that you are already out of luck,
Which is not to say that it won't work in some cases.
e.g. IdentityServer 3 does implement the hybrid flow.
Refer : IdentityServer : The WebApp-OpenIDConnect-DotNet Azure AD sample.
Here I show how to use the OWIN library to connect to IdentityServer 3. As you can see, I had to make some alterations.
Enjoy!
Microsoft has OWIN client libraries for OpenID Connect / OAuth2.
It also has ADAL - Active Directory Authentication Library (used mainly for native devices).
Both implement the protocols so you would think that you can use these to hook up to any server that implements OpenID Connect / OAuth.
Except that you would be wrong.
OAuth is notorious for incompatibility so you can't really mix and match.
These libraries are aimed at a specific use case i.e. the server is either Azure AD or ADFS.
In addition, the profile is hybrid flow so if your server doesn't implement that you are already out of luck,
Which is not to say that it won't work in some cases.
e.g. IdentityServer 3 does implement the hybrid flow.
Refer : IdentityServer : The WebApp-OpenIDConnect-DotNet Azure AD sample.
Here I show how to use the OWIN library to connect to IdentityServer 3. As you can see, I had to make some alterations.
Enjoy!
Thursday, October 08, 2015
AAD : The OpenID Connect / OAuth claims
There seems to be a lot of confusion regarding the claims delivered from Azure AD when you use the OWIN OpenID Connect plumbing.
I used the Github "WebApp-OpenIDConnect-DotNet" sample.
After authentication, I got back:
Notice that the top part of the claims follow the OAuth pattern e.g.
aud = audience
iss = issuer
iat = issued at
etc.
The bottom half (and there are others that didn't fit into the image) are the kind of claims that you get with claims-based identity e.g. the kind you get if you use the older WIF wrapper.
This isn't strictly OAuth but it does provide a way to "augment" the somewhat sparse OAuth claims set.
Also note that you do not get Roles OOTB.
To do this you need to change the AAD Application manifest.
Refer:
Azure Active Directory Part 4: Group Claims
Or you could just use the good, old Azure AD Graph API.
Enjoy!
I used the Github "WebApp-OpenIDConnect-DotNet" sample.
After authentication, I got back:
Notice that the top part of the claims follow the OAuth pattern e.g.
aud = audience
iss = issuer
iat = issued at
etc.
The bottom half (and there are others that didn't fit into the image) are the kind of claims that you get with claims-based identity e.g. the kind you get if you use the older WIF wrapper.
This isn't strictly OAuth but it does provide a way to "augment" the somewhat sparse OAuth claims set.
Also note that you do not get Roles OOTB.
To do this you need to change the AAD Application manifest.
Refer:
Azure Active Directory Part 4: Group Claims
Or you could just use the good, old Azure AD Graph API.
Enjoy!
Tuesday, June 16, 2015
ADFS : Playing around with Postman
This is for Active Directory Federation Services / "AD FS" / ADFS on Windows Server 2016 (currently Technical Preview 2).
My server is in an Azure VM.
I been playing around with Postman and the new OpenID Connect / OAuth2 features in ADFS.
But could not get it to work.
I contacted the Postman people who were very helpful and they advised me that the issue was that the SSL certificate on my VM is self-signed and hence causes the problem. There's no trust. Other than that, there appears to be no issues.
As this is a test VM and is going to be superseded when TP3 comes along, I don't really see any point in paying for a CA certificate.
But it would be nice to see it working :-)
Enjoy!
My server is in an Azure VM.
I been playing around with Postman and the new OpenID Connect / OAuth2 features in ADFS.
But could not get it to work.
I contacted the Postman people who were very helpful and they advised me that the issue was that the SSL certificate on my VM is self-signed and hence causes the problem. There's no trust. Other than that, there appears to be no issues.
As this is a test VM and is going to be superseded when TP3 comes along, I don't really see any point in paying for a CA certificate.
But it would be nice to see it working :-)
Enjoy!
Wednesday, May 27, 2015
ADFS : OpenID Connect
This is for ADFS vNext or ADFS 4.0 running on Windows Server 2016 (Technical Preview at the moment). (aka Active Directory Federation Services or "AD FS").
One of the new features is that support for OpenID Connect has been enabled.
I tried a number of clients (including Postman) and couldn't get any of them to work so I had to write my own.
Except that Dominick has already done most of the work - refer Writing an OpenID Connect Web Client from Scratch.
Fantastic - except that Github link doesn't work.
The revised one in the comments does but it is to the whole sample and it's not obvious which one to use. In fact, it's this:
Clients/MvcFormPostClient
Download all the samples because that's what the VS .sln file references.
It compiled no problem with VS 2013 on my PC.
Now if you've used Dominick's samples before, you'll know that they reference Dominick's environment so you have to ferret out all the references and change them,
But before we do that we have to find out what they are.
I run up the Technical Preview 2 in an Azure VM using my MSDN subscription. I then made it a forest of one by promoting the server to a DC so now I have AD, checked I have a certificate, created a service account and installed ADFS as a service exactly like Server 2012 R2.
(Note - after creating the Azure VM, you have to add endpoints for ports 80 and 443!).
In ADFS, click the Client tab and then "Add new OAuth Client". You need to set the settings as below because that's what the sample uses. "Name" can be anything.
Also of interest is the "Scope Descriptions":
These are the only scopes that are recognised by default.
You'll see the sample uses scopes "openid" and "email".
Back to VS,
In the Constants,cs file (part of the larger project), you need to edit for your endpoints:
Note that the ADFS OAuth2 endpoint is .../adfs/oauth2/authorize and similarly for token as above.
Houston - we have a problem with the ValidateIdentityTokenAsync method in the AccountController class.
The Github code does not match the code in the above link.
There was a later post - refer Using Discovery and Katana Middleware to write an OpenID Connect Web Client - and this matches the Github code.
In that code, you'll see:
var certString = "MIIC4jCCA..."
OK - see where does my certificate info. come from?
As per that post, it comes from:
https://ADFS.local/adfs/.well-known/openid-configuration
which returns JSON like:
and more - this is truncated. But nowhere in the JSON is there any certificate information.
The key is this line as above.
"jwks_uri": "https://ADFS.local/adfs/discovery/keys"
Browse to that URL and you'll see a "x5c" section:
x5c": [
"MIIC4j...
]
That Base64 string is what you paste into your code.for "var certString =".
And then you should be good to go.
Run the application, it will take you to the normal ADFS logon screen where you authenticate and then you will see:
If you use some sort of trace like "SAML Tracer" or Fiddler, you'll see a line like:
Now if you copy and paste this into a JSON viewer like:
http://jwt.io/
you'll see the same thing.
Enjoy!
One of the new features is that support for OpenID Connect has been enabled.
I tried a number of clients (including Postman) and couldn't get any of them to work so I had to write my own.
Except that Dominick has already done most of the work - refer Writing an OpenID Connect Web Client from Scratch.
Fantastic - except that Github link doesn't work.
The revised one in the comments does but it is to the whole sample and it's not obvious which one to use. In fact, it's this:
Clients/MvcFormPostClient
Download all the samples because that's what the VS .sln file references.
It compiled no problem with VS 2013 on my PC.
Now if you've used Dominick's samples before, you'll know that they reference Dominick's environment so you have to ferret out all the references and change them,
But before we do that we have to find out what they are.
I run up the Technical Preview 2 in an Azure VM using my MSDN subscription. I then made it a forest of one by promoting the server to a DC so now I have AD, checked I have a certificate, created a service account and installed ADFS as a service exactly like Server 2012 R2.
(Note - after creating the Azure VM, you have to add endpoints for ports 80 and 443!).
In ADFS, click the Client tab and then "Add new OAuth Client". You need to set the settings as below because that's what the sample uses. "Name" can be anything.
Also of interest is the "Scope Descriptions":
These are the only scopes that are recognised by default.
You'll see the sample uses scopes "openid" and "email".
Back to VS,
In the Constants,cs file (part of the larger project), you need to edit for your endpoints:
public static class Constants
{
//public const string BaseAddress = "https://localhost:44333/core";
public const string BaseAddress = "https://ADFS.local/adfs";
//public const string AuthorizeEndpoint = BaseAddress + "/connect/authorize";
public const string AuthorizeEndpoint = BaseAddress + "/oauth2/authorize";
public const string LogoutEndpoint = BaseAddress + "/connect/endsession";
//public const string TokenEndpoint = BaseAddress + "/connect/token";
public const string TokenEndpoint = BaseAddress + "/oauth2/token";
public const string UserInfoEndpoint = BaseAddress + "/connect/userinfo";
public const string IdentityTokenValidationEndpoint = BaseAddress + "/connect/identitytokenvalidation";
public const string TokenRevocationEndpoint = BaseAddress + "/connect/revocation";
public const string AspNetWebApiSampleApi = "http://localhost:2727/";
}Note that the ADFS OAuth2 endpoint is .../adfs/oauth2/authorize and similarly for token as above.
Houston - we have a problem with the ValidateIdentityTokenAsync method in the AccountController class.
The Github code does not match the code in the above link.
There was a later post - refer Using Discovery and Katana Middleware to write an OpenID Connect Web Client - and this matches the Github code.
In that code, you'll see:
var certString = "MIIC4jCCA..."
OK - see where does my certificate info. come from?
As per that post, it comes from:
https://ADFS.local/adfs/.well-known/openid-configuration
which returns JSON like:
{ "issuer": "https://ADFS.local/adfs", "authorization_endpoint": "https://ADFS.local/adfs/oauth2/authorize/", "token_endpoint": "https://ADFS.local/adfs/oauth2/token/", "jwks_uri": "https://ADFS.local/adfs/discovery/keys", "token_endpoint_auth_methods_supported": [ "client_secret_post", "client_secret_basic", "private_key_jwt", "windows_client_authentication" ], "response_types_supported": [ "code", "id_token", "code id_token", "token id_token" ], "response_modes_supported": [ "query", "fragment", "form_post" ], "grant_types_supported": [ "authorization_code", "refresh_token", "client_credentials", "urn:ietf:params:oauth:grant-type:jwt-bearer", "implicit", "password" ],
and more - this is truncated. But nowhere in the JSON is there any certificate information.
The key is this line as above.
"jwks_uri": "https://ADFS.local/adfs/discovery/keys"
Browse to that URL and you'll see a "x5c" section:
x5c": [
"MIIC4j...
]
That Base64 string is what you paste into your code.for "var certString =".
And then you should be good to go.
Run the application, it will take you to the normal ADFS logon screen where you authenticate and then you will see:
If you use some sort of trace like "SAML Tracer" or Fiddler, you'll see a line like:
Now if you copy and paste this into a JSON viewer like:
http://jwt.io/
you'll see the same thing.
Enjoy!
Subscribe to:
Posts (Atom)