search

bigfork / silverstripe-oauth

SilverStripe OAuth2 authentication, based on the PHP League's OAuth2 client
BSD 3-Clause "New" or "Revised" License
9 stars 11 forks source link

Changing Member Creds, decouples from IDP #21

Open phptek opened 2 months ago

phptek commented 2 months ago

I'm unsure if this is a problem with the module, or the following behaviour is by design and the problem needs to be resolved with user config changes in the IDP/ID broker.

My Setup uses OIDC in Keycloak as the identity broker, with OpenLDAP as the IDP, and for logging-in/out, everything works A-OK.

The problem is that once a user is authenticated through Keycloak/LDAP and their Member account is auto-created in Silverstripe, I can go-ahead and change the user's credentials in Silverstripe, logout+login again through Keycloak, while using the old credentials.

I'm not expecting this module to have magically updated Keycloak/LDAP, but what I would expect is for the user's credentials to be re-checked as being valid in Silverstripe at the point of redirection back to Silverstripe.

So for an existing "SSO User" who has had their first password subsequently changed in Silverstripe and not in the IDP:

Expected Workflow

"Login with Keycloak" (Silverstripe) > Enter Old Credentials (Keycloak) > Redirect (to Silverstripe) > Validate incoming user > Error

Observed Workflow

"Login with Keycloak" (Silverstripe) > Enter Old Credentials (Keycloak) > Redirect (to Silverstripe) > Success

Setup:

silverstripe/framework 5.2 bigfork/silverstripe-oauth 2.2.2 bigfork/silverstripe-ouath-login 2.3 stevenmaguire/oauth2-keycloak 5.1

kinglozzer commented 2 months ago

It’s been a while since I’ve worked on this module and I’ve been off all week with flu, so please double check my thinking...

The way I’ve always thought about this is that it’s up to the IDP to decide whether the user has access to the email address in question. If they do, then they can authenticate as that email address with any site/service that decides the IDP is trustworthy enough.

E.g. if I add “Log in with Google” for the CMS, I’m implicitly trusting that Google do enough on their end to stop a takeover of the account that’s using that email address. So changes on the Silverstripe side shouldn’t really matter - if I can log in to Google as user@gmail.com then I can also log into Silverstripe (and any other service that trusts Google as an IDP) as user@gmail.com too.

If you change the password in Silverstripe (or even delete the account entirely) but the user can still log in to the IDP with the email address, then the account would just be recreated right? The IDP is the essentially “source of truth” for whether a user has access to that email address.