Auto-redirect to external IdP

[sanjeev-saxena-us]

IdentityServer version

7

.NET version

8

Description

I am working on a POC where I need to have IdentityServer behave as Federation Gateway (similar to https://docs.duendesoftware.com/identityserver/v7/ui/federation/).

However, I need to have this IdentityServer not go thru a home realm discovery via the UI but auto-redirect to the external IdP. The detection will be done using the client-id in the connect/authorize request. What I am experiencing is that the IdentityServer is always presenting it's login UI with the buttons for each external IdP.

I am unsure as to where to put this detection logic in the local IdentityServer so that the auto-redirect kicks in; Any working sample and/or suggestions would be highly appreciated!

Reproduction steps

No response

Expected behavior

IdentityServer recieves the connect/authorize request with the client-id and after after my logic determines which external Idp to use, redirect user to that IdP without IdentityServer's UI for home realm discovery.

Logs

No response

Additional context

No response

[StuFrankish]

Heya @sanjeev-saxena-us 👋

Getting IdentityServer to auto-redirect to an external provider is relatively easy - I'll assume you don't need to logically switch between multiple external providers for the same client, just that depending on the client, you need to always redirect to a specific external provider (do correct me if I'm wrong).

Have you looked at the EnableLocalLogin and IdentityProviderRestrictions properties in the client configuration?

Setting EnableLocalLogin to false, will remove the username & password fields from the default UI.
Specifying external providers in the IdentityProviderRestrictions collection will restrict that client to just the specified providers.
See the documentation here: Client :: Duende IdentityServer Documentation

Where there being only 1 external provider and no local login, your client should be redirected to that external provider automatically.

I did have a working demo of this a few weeks ago, but I don't think I committed the branch and can't remember what I did with the project locally 😅 If I happen to find it I'll link to the branch.

[sanjeev-saxena-us]

Hey @StuFrankish ,

Thanks for the suggestions.
I am leveraging DynamicProviders.
IdentityServer is running on 5001. client app is running on 44300

In IdentityServer, modified code based on your suggestions:
Provider:

var p = new OidcProvider
{
    Scheme = "demoidsrv",
    DisplayName = "IdentityServer (dynamic)",
    Authority = "https://demo.duendesoftware.com",
    ClientId = "login",
};

Client:

var c = new Client
{
    ClientId = "login",
    ClientSecrets = { new Secret("secret".Sha256()) },

    AllowedGrantTypes = GrantTypes.Code,

    RedirectUris = { "https://localhost:5001/signin-oidc" },
    FrontChannelLogoutUri = "https://localhost:5001/signout-oidc",
    PostLogoutRedirectUris = { "https://localhost:5001/signout-callback-oidc" },

    EnableLocalLogin = false,
    IdentityProviderRestrictions = new[] { "demoidsrv"},
}

I am getting the following:

Questions:

1. Does the RedirectUris need to be for the client app and not the IdentityServer's?
2. If I changed the RedirectUris to that of the client app ie. https://localhost:44300/signin-oidc it still fails as above; however if I make the following call:
3. c.RedirectUris.Add("https://localhost:44300/signin-oidc") I do get the following:
   

The failure is here:

However, as a test, if I replace the line identified in the above image with (notice that I removed "/Index"):
return RedirectToPage("/ExternalLogin/Challenge", new { scheme = View.ExternalLoginScheme, returnUrl });
I get redirected to the demo duende idp

Thoughts?

[sanjeev-saxena-us]

Now, being auto-redirected and after being authenticated by the external IdP https://demo.duendesoftware.com, I do get redirected back to the client app but am getting the following:

@StuFrankish any chance you have been able to find the working example branch?

[StuFrankish]

Hi @sanjeev-saxena-us 👋

Unfortunately I wasn't able to locate the concept branch I had working, I'll see if I can rebuild it but that'll be if I get some free time.
From your latest error though, it looks like your being correctly redirected, but the client isn't getting an Id Token back and that's resulting in the exception you're seeing.

You should be able to verify that by setting the event handler in your clients OpenIdConnect configuration like this;

.AddOpenIdConnect(OpenIdConnectDefaults.AuthenticationScheme, options =>
{
    // Usual config
    // ...

    options.Events.OnTokenResponseReceived = context =>
    {
        var idToken = context.TokenEndpointResponse?.IdToken;

        return Task.CompletedTask;
    };

    // rest of config
    // ...

});

Putting a breakpoint on the return and inspecting the IdToken value provided in the TokenEndpointResponse will likely come up null.
There could be a number of reasons that might be happening, often because the OpenIDConnect scope or flow is misconfigured.

Have you got a public repo we could have a look at?

Quick edit:
I noticed that your client configuration doesn't specify openid as an allowed scope.
Is that configured and just not shown here? As I recall, that scope is required in order to receive an Id Token.

[sanjeev-saxena-us]

Hey @StuFrankish,

Yeah, great catch re: openid scope! It indeed was the openid scope that was missing from:

1. client app which I added
2. in the IdentityServer ApiScopes collection which I added as:

(Note: I have a class that implements IResourceStore and in this class I am adding just the following):
this.resources.ApiScopes.Add(new ApiScope("openid")); // this.resources is a readonly private data member of this class

I am not adding any IdentityResources (difference between ApiResources and IdentityResources?)

Additionally, how do I ensure that the email claim is returned from the externalIdP? I am getting an interesting "sub":

Yeah, I'll push into my repo after I've had a chance to clean it up a bit :)
Thanks

[StuFrankish]

Heya @sanjeev-saxena-us 👋

Identity Resources are the claims that go together to make up what a user is.
There are a few defaults you can use to request specific information about a user.

An identity provider can advertise which scopes it supports in the /.well-known/openid-configuration endpoint, for example;

  "scopes_supported": [
    "email",
    "openid",
    "profile",
    "offline_access"
  ],

Your client must be allowed them, and must request them as part if its configuration in order to receive them.

API Resources on the other hand, represent the functionality a client wants to access on your behalf.

So to answer this;

how do I ensure that the email claim is returned from the externalIdP?

Ensure that the scope is supported (it should be), your client is allowed the email scope and that your client requests it as part of its configuration. If the provider doesn't explicitly mention email as a supported scope, it's likely that the claim could be included as part of another scope, so it's worth reading the documentation in those instances.

[sanjeev-saxena-us]

Hey @StuFrankish,

Ok, after your suggestion, in my local IdentityServer, I am now getting profile related claims from the demo.duendesoftware.com external IdP (verified by looking at the token at jwt.io) but when the token get sent back to the client app that made the original aythN request to my local IdentityServer, all these claims are no longer present.

In the client app, I have the following configuration:

    .AddOpenIdConnect("oidc", options =>
    {
        options.Events.OnTokenResponseReceived= context =>
        {
            return Task.CompletedTask;
        };
        options.Events.OnAuthenticationFailed = context =>
        {
            return Task.CompletedTask;
        };
        options.Authority = Urls.IdentityServer;
        options.RequireHttpsMetadata = false;

        options.ClientId = "SomeClientId";
        options.ClientSecret = "secret";

        // code flow + PKCE (PKCE is turned on by default)
        options.ResponseType = "code";
        options.UsePkce = true;

        options.Scope.Clear();
        options.Scope.Add("profile openid");

        // not mapped by default
       // options.ClaimActions.MapJsonKey("website", "website");

        // keeps id_token smaller
        options.GetClaimsFromUserInfoEndpoint = true;
        // save tokens in cookie
        options.SaveTokens = true;
        // disable MS auto claim type renaming
        options.MapInboundClaims = true;
        //Disable x-client-SKU and x-client-ver headers (security issue)
        options.DisableTelemetry = true;

        options.TokenValidationParameters = new TokenValidationParameters
        {
            NameClaimType = "name",
            RoleClaimType = "role"
        };
    })```