loginRedirectUrl

[lamboap]

hi,

we have gotten SSO working with 0kta nearly seamlessly, thanks. I've created a second site because we're using craft as a headless CMS. I've setup a redirect in general.php to have a general landing page after logging in.

'postLoginRedirect' => App::env('LOGIN_REDIRECT_URL')

this works when logging in from the craft cms login page. (SP initiated log in) Is there a way I can redirect login requests if a user is clicking craftcms icon on Okta (IdP initiated log-in)? I had tried updating the default relay state with the absolute path of where to redirect to after logging in. This was unsuccessful

[dsmrt]

👋 @lamboap

Expected behavior is every user that clicks the button in Okta, will be redirected to the same place, correct?

You may need to add RelayState as a GET parameter and base64 encode the value (RelayState=/my-page but ‘/my-page’ is base64’d … it can be an absolute url too).

Also, the postLoginRedirect might be messing with the result but i’m not sure. I’m not certain how that works. You may want to test commenting it out. Or, actually, it might not be utilized since the plugin is preforming the login and redirect. 🤔

[lamboap]

I pulled the postLoginRedirect and SP initiated login is fine, clicking the login button on the login page on Craft. How is the link on that button created? I see a RelayState added as a GET parameter to the Okta url.

My issue is on the Okta side. If I create a RelayState parameter on the Okta side it should redirect to that url after a successful login, this isn't the observed behavior. I am logged in but not redirected. I'll base64 encode the url and reattempt.

[dsmrt]

How is the link on that button created?

I assume you are asking about the CP login "Via" buttons?

Below's how I do it for the login page, but since this is SP initiated I assume it's not yet base 64 encoded. IdP needs to send the relay state base64 encoded. Also note that those "Via" buttons are sending the user to the request login endpoint where you'll be sending the user to login endpoint (/sso/login/request/<idpUid> vs /sso/login/<spUid>).

https://github.com/flipboxfactory/saml-sp/blob/42fb5558dd3576976a07f76cfc9fe997ad81d2e1/src/templates/_cp/login.twig#L95

As for your issue on the Okta side, make sure to base64 the uri. You can run something like this in the term:

echo -n "/admin/dashboard" | base64
# result 👉  L2FkbWluL2Rhc2hib2FyZA==

Place the result in the Default RelayState (as shown in this screenshot):

Then make sure "info" level logging is on and see what shows up in the logs if you are still having issues.

There is good logging like this:

storage/logs/web.log:2021-09-13 13:36:50 [-][2][-][info][saml-sp] RelayState: https://sp.localhost:8081/protected
storage/logs/web.log:    'RelayState' => 'aHR0cHM6Ly9zcC5sb2NhbGhvc3Q6ODA4MS9wcm90ZWN0ZWQ=' 

Here's a helpful command, to tail and watch the logs while you test login:

tail -f craft-sp/storage/logs/web.log | grep -A 10 '\[saml-'

[lamboap]

Thanks again. that was the issue. I wasn't base64 encoding the relay on the Okta side. I can log in via Okta on Craft and directly from Okta to Craft. I'm just in time provisioning them to an "editor" group from Okta to Craft with the correct permissions. Kudos to your work, this has been a smooth integration.

[dsmrt]

@lamboap thank you so much for the kind words. 😊 SAML is a tricky beast -- there's a lot of confusing concepts -- but it's awesome when things come together.

Closing this now but let me know if there's anything else that pops up.

🙏