AS does not do its own authentication – that’s by design. When you download from the repo, AS is set up to be a WS-Federation relying party. In the configuration folder of the WebHost project you’ll find two config files: identity.config and identityservices.config that wire up AS to an IdP.

<system.identityModel.services>

  <federationConfiguration>

    <wsFederation passiveRedirectEnabled=“true“

                  issuer=“https://idsrv.local/issue/wsfed“

                  realm=“urn:authorizationserver“ />

  </federationConfiguration>

</system.identityModel.services>

You can change these settings to connect to your own IdP, e.g. IdentityServer, ADFS, ACS or WAAD. The “Identity & Access” VS plugin makes it even easier to “auto-configure” AS (just don’t forget to remove the pesky authorization elements from web.config).

AS really only needs a single claim on the current principal to function properly – sub – the subject identifier claim from the JWT spec. It’s the job of claims transformation to provide this claim after authentication has happened. For this purpose AS comes with a pre-defined claims authentication manager that turns incoming NameIdentifier or Name claims into a sub claim. That works out of the box for the above mentioned IdPs:

public class NameIdToSubjectClaimsTransformer : ClaimsTransformerBase

{

    public NameIdToSubjectClaimsTransformer(

      IAuthorizationServerAdministratorsService svc)

        : base(svc)

    { }

    protected override Claim GetSubject(ClaimsPrincipal principal)

    {

        var nameId = principal.FindFirst(ClaimTypes.NameIdentifier);

        if (nameId == null)

        {

            nameId = principal.FindFirst(ClaimTypes.Name);

            if (nameId == null)

            {

                throw new InvalidOperationException(

                  "No nameidentifier claim");

            }

        }

        return new Claim(Constants.ClaimTypes.Subject, nameId.Value);

    }

}

If your IdP uses a different mapping, simply change the implementation of GetSubject. If you want to wire up a different claims transformer altogether, you can find the relevant code in global.asax.

If you don’t use an IdP at all, you can also add a local login form to AS or switch to Windows authentication. In that case simply run the claims transformer in PostAuthenticateRequest to provide the sub claim.

The second authentication related plumbing is for the OAuth2 resource owner password flow. Since AS does not do authentication, the credential validation needs to be delegated. By default we do that using WS-Trust to the same IdP that takes care of the web login. This is implemented in the WSTrustResourceOwnerCredentialValidation class, and configured in autofac.config:

<component type=" WSTrustResourceOwnerCredentialValidation …"

            service=" IResourceOwnerCredentialValidation … " >

  <parameters>

    <parameter name="address"

               value="https://idsrv.local/issue/wstrust/mixed/username" />

    <parameter name="realm"

               value="urn:authorizationserver" />

    <parameter name="issuerThumbprint"

               value="BFF6C249A2FFAA51A959B422DAAEDCF10E8A38EB" />

  </parameters>

</component>

Again, you can take control over that process be implementing IResourceOwnerCredentialValidation and wire it up in above config.