IdP Initiated SSO

[tyduptyler13]

IdP Initiated SSO / Launchpad

Problem

It is hard for a user to easily navigate to all of the supported websites and easily be authenticated.

Solution

The barrier could be reduced by using an IdP initiated login via a launchpad. This gives users two things:

1. A collection of easy to reach applications
2. A faster route to be authenticated with the applications

Alternatives/workarounds

Keep bookmarks in the browser and manually find the login button for any of these features.

Additional context

• https://blogs.oracle.com/dcarru/sp-vs-idp-initiated-sso
• https://auth0.com/docs/protocols/saml/idp-initiated-sso
• https://github.com/keycloak/keycloak-documentation/blob/master/server_admin/topics/clients/saml/idp-initiated-login.adoc
• https://duo.com/blog/the-beer-drinkers-guide-to-saml (Good article)

Considerations

In researching this workflow, most other providers use SAML as it has a specifically designed mechanism for it.

• OpenID Connect Implementation

  • OpenID doesn't have an official spec for implementing an IDP initiated SSO and in fact has a few barriers to doing so. Example: The IDP initiated workflow skips to the authorization callback on the SP but the SP requires a state variable that would normally be passed to the authorize endpoint, this results in failure because the state is missing. In order to allow this to work properly the client may need to allow requests without that state which could be a security risk as the state is frequently used as a CSRF mechanism.

• SAML - Both 1.1 and 2.0 support this

• OWASP Security

  • https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html#unsolicited-response-ie-idp-initiated-sso-considerations-for-service-providers

  Unsolicited Response is inherently less secure by design due to the lack of CSRF protection. However, it is supported by many due to the backwards compatibility feature of SAML 1.1. The general security recommendation is to not support this type of authentication,

Related

• https://github.com/FusionAuth/fusionauth-site/issues/29#issuecomment-641457437
• https://github.com/FusionAuth/fusionauth-site/issues/29#issuecomment-676433285

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

[tyduptyler13]

Workflows

IdP Initated workflows (SAML/OIDC)

PUML Source

```PlantUML @startuml title Authenticated Launchpad Launchpad: GET to / [*] --> Launchpad Launchpad --> SelectTenant SelectTenant --> Login SelectTenant --> SelectTenant: Unknown tenant name Launchpad --> Login: Only one tenant Login --> Login: Unsuccessful login Login --> SelectApplication Login --> IDPInitatedLogin: Only one application SelectApplication --> IDPInitatedLogin IDPInitatedLogin --> [*] @enduml @startuml title NOT Authneticated Launchpad Launchpad: GET to / [*] --> Launchpad Launchpad --> SelectTenant Launchpad --> SelectApplication: Only one tenant Launchpad --> IDPInitatedLogin: Only one tenant AND\na default application SelectTenant --> SelectApplication SelectTenant --> SelectTenant: Unknown tenant name SelectApplication -> IDPInitatedLogin SelectTenant --> IDPInitatedLogin: Default application IDPInitatedLogin --> [*] @enduml @startuml title OpenID IDP Initiated Login user -> FA: SP link on launchpad note right The url contains information on which client to go to. Using that info we can decide between the following workflows end note alt SP requires State FA --> user: 302 to SP Login user -> SP: / return 302 to FA Oauth user -> FA: /oauth2/authorize return 302 to SP callback else SP doesn't require state and we know the callback note over user, SP Warning: This workflow is considered a security risk due to the lack of the State variable. It is possible to have a man in the middle attack. (This is also true for the SAML workflow) end note FA --> user: 302 to /login user -> FA: /login note right This ensures we are logged in end note FA --> user-: 302 to SP callback end user -> SP+: / SP -> FA+: /oauth2/token return SP -> SP: Decode token SP --> user-: 302 to landing page user -> SP+: / return @enduml @startuml title SAML IDP Initiated Login note over user, FA Warning: This strategy contains a vulnerability to man in the middle attacks as anyone can phish the users into using their interface and act on behalf of the user. end note user -> FA: SP link on launchpad return 302 /samlv2/login user -> FA: /samlv2/login return 302 to SP RelayState note over user, FA The user has a token now end note user -> SP+: RelayState url (known by FA) SP -> SP: Validate token SP --> user-: 302 to landing page user -> SP+: / return @enduml ```

[voidmain]

It looks like the workflow for OpenID Connect isn't fully backed for the "SP doesn't require state". It should take the user to /oauth2/authorize

[tyduptyler13]

@voidmain The docs i've been reading suggest that you can skip authorize and just send the user to the SP callback with an authorization token (as if they already did the SP login and called authorize). I can document that.

[voidmain]

Not if they aren't logged into the OAuth endpoint of the IdP. That would be a HUGE security risk. If you want to cover every case for IdP initiated login, then technically you need 6 diagrams:

1. OAuth no session, state needed
2. OAuth no session, no state needed
3. OAuth session, state needed
4. OAuth session, no state needed
5. SAML no session
6. SAML session

[tyduptyler13]

I agree that it is a huge risk. The two things I've grasped from reading about this is that its always insecure (because there is little to nothing protecting you from man in the middle), with the exception of my first OpenID option (state required) (because that is just OpenID Connect with a little bootstrapping), and that Auth0, Oracle, KeyCloak, and Duo seem to do it anyways.

As for the session, I believe I made an assumption that the only way to reach the launchpad is if the user is already logged in to FusionAuth. As for the SP session, it would have to be created as the user triggered the SP callback.

[tyduptyler13]

A good route forward would probably be to "support idp initated login", but actually just route everyone to the SP login page with the right parameters to trigger a FusionAuth login (regardless of Oauth or SAML). It would still look like idp initated login but be more secure. We could even make a blog post on why we did it that way and why its a bad idea to skip steps in a login workflow.

[robotdan]

This will be shipping shortly, however it is only for IdP initiated login support through SAML v2. The launchpad capability within FusionAuth will be a separate feature. We will ship IdP initiated login under this issue, and then possibly open a new issue for the full launchpad idea within FusionAuth.

In an upcoming feature for additional MFA support, there will be an end user account management page and a landing page. Some of the launchpad ideas could be implemented on these pages by an end user.

[crossan007]

@robotdan Is there a separate issue I can follow for the "Launchpad" feature?

I'm looking for a kind of "Application directory" for (authenticated) FusionAuth end users where they can see all of the apps available to them, and click a link to launch directly into the app (IdP initiated workflow; starting from FusionAuth).

[robotdan]

Some of this is possible today - depending upon your needs. There is a set of self-service pages you can expose to your user, and a root landing page that can be themed. You may be able to build links or launch points into other applications here by building an OAuth Authorize URL on these pages.

But we don't have an official GH issue open to track the feature for a more built-in configurable launch pad. Please do open one if you are interested in this feature.

[crossan007]

@robotdan nice! That may actually fit my needs perfectly, since it seems that there are some security concerns around IdP initiated logins, and launching right into the SP's login page (possibly with a query string instructing the SP to being the SP-initiated login with the FusionAuth IdP) is the preferred mechanism anyway.