Thursday, December 06, 2018

Exception details:
Microsoft.IdentityServer.Web.InvalidRequestException: MSIS7042: The
same client browser session has made '6' requests in the last '7'
seconds. Contact your administrator for details.

There are many causes for this; one being the "missing /" on the identifier.

I found one recently where I was running an ASP.NET MVC application inside VS that was authenticated via ADFS. This used the OWIN WS-Fed middleware.

I couldn't authenticate because of this error.

ADFS will only accept https connections so the RP was configured with a:

Friday, July 06, 2018

I see this error so many times. It is generally on the client side as part of the .NET framework.

The root cause of this is:

Your server certificate is self-signed

You are using an incorrect host name to connect

Your certificate is not trusted

The host name must match the subject name on the certificate e.g. company.com and orders.company.com both point to the same URL but the certificate has been issued to company.com. So that is the name you need to use to get to the web site. Or else you can add the other names to the SAN.

If the certificate is not trusted, you can add it to the "Trusted Root Certification Authorities". But be mindful of security.

Often this question means ‘how long do users get single sign on (SSO) without having to enter new credentials, and how can I as an admin control that?’ This behavior, and the configuration settings that control it, are described in the article here.

The default lifetimes of the various cookies and tokens are listed below (as well as the parameters that govern the lifetimes):

Registered Devices

PRT and SSO cookies: 90 days maximum, governed by PSSOLifeTimeMins. (Provided device is used at least every 14 days, which is controlled by DeviceUsageWindow)

Refresh token: calculated based on the above to provide consistent behavior

access_token: 1 hour by default, based on the relying party

id_token: same as access token

Un-registered Devices

SSO cookies: 8 hours by default, governed by SSOLifetimeMins. When Keep Me Signed in (KMSI) is enabled, default is 24 hours and configurable via KMSILifetimeMins.

Refresh token: 8 hours by default. 24 hours with KMSI enabled

access_token: 1 hour by default, based on the relying party

id_token: same as access token"

And here we see the first problem - there is a major distinction between registered and unregistered (aka non registered) devices and most of the documentation is for the former.

A registered device is a device that has been provisioned via EMS / Intune. You could add domain-joined here. This allows a user to BYOD and still have access to a company's intranet.

So if you have a customer with a B2C type of scenario where their users have a wide range of devices and never need to access the company intranet, you start to see some problems.

The first issue is that of persistent cookies.

Set-AdfsProperties –EnablePersistentSso

These are not enabled for unregistered devices. You can turn them on with the KMSI (Keep Me Signed In) option.

Set-AdfsProperties -EnableKmsi $true

What you now see in a PC browser is:

and indeed the cookies are now persistent if you tick the box.

The defaults have changed from 8 hours to 24 as above.

However, on some mobile devices, the onload.js has a:

style="display:none"

which means that it does not display and you are back to square one.

This may be because there is a:

"&prompt=login"

in the query string,

So assuming KMSI is on, you have:

access token = id-token = 1 hour

SSO cookie = refresh token = 24 hours

To change the default:

Set-AdfsProperties – KmsiLifetimeMins int32

and if KMSI is off:

access token = id-token = 1 hour

SSO cookie = refresh token = 8 hours

To change the default:

Set-AdfsProperties –SsoLifetime int32

Also note that there is a KMSI "user component" (which adds the box) and a KMSI "ADFS feature" (that changes the timeout values).

You don't want the refresh token to time out because that would force the user to re-authenticate.

So you can use the "authorize" endpoint to get a brand new set of tokens. Because the SSO cookie has not yet expired, ADFS will simply mint a new set without any login requirement.

The tokens are "brand new" e.g the id-token will be valid for another hour.

By a "new set", I mean an access token, a refresh token and an id-token.

You get the same behaviour if you call the refresh endpoint.

However, I noticed that although the value of the refresh token is different, it has the same

"The root cause of MSIS9642 is that the new OpenID Connect Application Group features in ADFS 2016 need to issue an access token to your application. This token must include the users identity. In order to issue the token the subsystem must understand which claim in the inbound claims is used to uniquely identify the user.

A new property called AnchorClaimType has been added to the Claim Provider Trust model."

Note that this property is not available on a RP trust.

The PowerShell needs to be run on the CP server i.e. ADFS A.

(Get-AdfsClaimsProviderTrust -Name "CP name").anchorclaimtype

This will be blank the first time. You can use any attribute that makes sense to uniquely identify the user. Typically, this would be sAMAccountName or UPN.

Monday, February 12, 2018

Using Postman for the Authorisation Code Grant on Server 2016 (ADFS 4.0) is documented here.

Then someone asked me how to extend this to get a new access token using the refresh token.

Recall that the second part of the code grant is to send a code to the /token endpoint that returns an access token, a refresh token and an ID token.

To get a new access token, we use the same /token endpoint with the parameters above and the same refresh token that we received as described above.

This returns an access token and an ID token. It does not return another refresh token?

So back to the OAuth spec (RFC 6749) section:

6. Refreshing an Access Token

"If valid and authorized, the authorization server issues an access
token as described in Section 5.1. If the request failed
verification or is invalid, the authorization server returns an error
response as described in Section 5.2.

The authorization server MAY issue a new refresh token, in which case
the client MUST discard the old refresh token and replace it with the
new refresh token.

The authorization server MAY revoke the old
refresh token after issuing a new refresh token to the client. If a
new refresh token is issued, the refresh token scope MUST be
identical to that of the refresh token included by the client in the
request."

So that is correct.

Note that you can use this refresh token over and over again until it expires and each time you will get a new access token.

There's a good write-up here around configuring the refresh token timeouts etc.