Bug w/ External "SSO" Provider having Multiple Clients

[b-earendil]

Which version of Duende IdentityServer are you using?
v7.0.0

Which version of .NET are you using?
v8.0.204

Describe the bug

• We have a Duende Identity Server License

• We have two Web Clients.

• Each has its own IdentityServer project based off of "QuickStart 2 - Interactive Applications with AspNet Core".

• We have a third IdentityServer project which is meant to server as an external "SSO" Identity Provider.

• After using the External SSO Provider to login to one of our Web Clients, attempting to do the same with the other Web Client logs the user out of the SSO External Provider, as well as the first Web Client.

To Reproduce

1. Clone : https://github.com/b-earendil/duende-external-provider
2. Launch : each of the following projects

• 1_IdentityServer
• 1_WebClient
• 2_IdentityServer
• 2_WebClient
• SSO_Identity_Server

3. Login : with 1_WebClient using "External Account > Custom-SSO"

• Credentials: uname - bob, pw - bob
• Note: Observe that the user is successfully logged in to 1_WebClient

5. Login : with 2_WebClient using "External Account > Custom-SSO"

• Credentials: uname - bob, pw - bob
• Note: Upon clicking Custom-SSO the user is not automatically logged in to WebClient2. Instead, they are prompted to re-enter the SSO login credentials.
• Note: Upon re-entering the SSO-login credentials, the user will be logged out of 1_WebClient and logged into 2_WebClient.

Expected behavior

1. Clone : https://github.com/b-earendil/duende-external-provider
2. Launch : each of the following projects

• 1_IdentityServer
• 1_WebClient
• 2_IdentityServer
• 2_WebClient
• SSO_Identity_Server

3. Login : with 1_WebClient using "External Account > Custom-SSO"

• Credentials: uname - bob, pw - bob
• Note: Observe that the user is successfully logged in to 1_WebClient

5. Login : with 2_WebClient using "External Account > Custom-SSO"

• Credentials: uname - bob, pw - bob
• Note: Upon clicking Custom-SSO the user should be automatically logged into 2_WebClient.. without being prompted again for their SSO login credentials.. and they should remain logged in to 1_WebClient as well.

Additional context

Our intention is to build a custom SSO solution which will work with a number of pre-existing web applications--each with their own existing 'Auth' project. Within the SSO_Identity_Server UserStore, each user has an associated claim for each web application for which they have access. Each claim contains the UserId of the user within one specific web application's IdentityServer.

Example: Within the SSO_Identity_Server UserStore, the user Bob has claims

• new Claim("Client1_UserId", "2") // Bob is UserId 2 in 1_IdentityServer
• new Claim("Client2_UserId", "12") // Bob is UserId 12 in 2_IdentityServer

When a user attempts to access 1_WebClient, they must login with 1_IdentityServer. We provide a "Custom-SSO" button on this login screen that allows them to login via the external-provider SSO_Identity_Server instead. Behind the scenes, 1_IdentityServer will act as a Client to SSO_Identity_Server.. displaying the SSO_Identity_Server login page to the user. After entering their SSO_Identity_Server credentials, the user is logged in with the external-provider and 1_IdentityServer receives the claim information from SSO_Identity_Server indicating which user from its internal user store should be logged in. Finally, this user should be logged in.

If the user then attempts to access 2_WebClient, we would expect the Custom-SSO button to

• automatically log the user in without prompting for re-entry of SSO credentials
• leave the logged-in state of 1_WebClient untouched

[RolandGuijt]

Can you please elaborate on why you need this complicated setup?
Why isn't it possible in your case to just setup one IdentityServer instance for both clients (looking at the example code). There should be no need for three instances in this example.

[TedCorrales]

Hi,
I'm Ben's coworker & responding on his behalf since he's in meetings all day today and we're working together on this project.

In our actual use case, we have multiple pre-existing web applications each with their own authentication solution and their own storage solution for account / profile information. Each is also managed and maintained by separate groups within our organization. In order to create a better end-user experience we want to create SSO functionality for clients who have access to more than one of our web applications.

We came up with the design above as a solution to implement SSO without having to remove or dramatically rewrite each application's auth/storage solutions. The idea being that each application would just need to add our SSO server as an "external provider" and then write a small amount of code to log in the correct user from their own system.

If there is a better way to do what we're describing I am all ears but removing all the existing auth systems to create a new unified one is unfortunately not an option at the moment.

[RolandGuijt]

You mention that each web application has its own specific account/profile information.

In a scenario where just one identity provider is used that can be maintained. The only thing that needs to be done is to associate the data for each user to the subject id (user id) that is provided by the identity provider. Claims that are relevant to all web applications can then be provided by the identity provider and application specific user data can stay on the level of the web application itself.

Is that a possible solution? Having one identity provider per web application defeats the main benefit of using OAuth/OpenID imo. Also: a license will be required for each instance of IdentityServer.

[RolandGuijt]

@TedCorrales Did my comment solve it for you? If so I'd like to close the issue.

[TedCorrales]

Hi Roland,

I might need a little more clarification here.

As mentioned above, this SSO design is meant to build on top of multiple existing web applications that each have their own identity provider.

We have a few requirements for our solution:

1. Users of each web application should be able to continue to access those web applications using their individual existing login credentials. (i.e. Bob may have credentials bob1, pwd1 for web app 1, and credentials bob2, pwd2 for web app 2.)
2. Users should also be able to log in to each web application using a single set of SSO login credentials. (i.e. once Bob has linked his accounts with us, he should be able to sign into web app 1 or web app 2 with bobSSO, pwdSSO)
3. Once logged in with their SSO credentials, users should be able to access any of the applications associated with that set of credentials without having to re-enter them, and without logging them out of any of the other applications.

There are certainly different design decisions we would make if we could rebuild this from the ground up, but unfortunately, we don't have that option at the moment.

I think what we're trying to do is similar to what you've suggested, but we need to retain the ability for users to login with their existing credentials from the existing identity providers, which is why we decided to try adding this new SSO system as an external provider within those systems (since we can't get rid of them anyway).

Regardless, I'm still not clear on why the design provided in our minimal reproduction doesn't work, so maybe some insight into that would help us form a better solution.

--Ted

[maartenba]

(note: we're moving this issue to our new community discussions)

[AndersAbel]

I think the immediate reason that your sample doesn't work is that you haven't set explicit names for the cookies for each of your applications/IdentityServers. When running on localhost, they will simply overwrite each others cookies. You need to set explicit names for the authentication cookie on each client/IdentityServer.

I would also like to comment on the architecture. It is (almost never) a good idea to have multiple IdentityServers in parallel or chained as upstreams as you have suggested. It makes the architecture more complex and as each IdentityServer has its own authentication session there are more ways where the sessions can be inconsistent.

We would be happy to work with you on the architecture and explore options on how to address your requirements, through our remote consulting services.