I am trying to use OKTA for the control panel only (and have it be the only option to login), while using another provider for the front end

[J-Protz]

Is this possible via this plugin? We are already using a provider on the front end, and now the client wants to use OKTA to sign in to the CP. I looked through the docs but am honestly pretty new to this and could use some help.

OKTA is being used for security, so I want to remove the option to login via normal means entirely. This also needs to not affect the front end.

I did look through the docs and previous issues but didn't see anything that was quite what I was looking for.

[dsmrt]

Yes! This is considered IdP initiated login. Okta will have an app for craft (after you configure it). Then you can click the button and it’ll login the user in.

[dsmrt]

@J-Protz Let me know if you need any more help here. Closing for now.

[J-Protz]

Hey there @dsmrt , I am finally trying to integrate this.

I have configured it to what I thought was correct, when I get to the admin, I click the button and it brings me to okta. I sign in, and it brings me back to the CP, however it's not logging me in. I am pretty new to SSO so I am having trouble debugging this, not seeing much in the network tab

The other thing is we will need to somehow completely disable the normal login button(s) and form from appearing, as this would defeat the security measure in place. Could you help point me in the right direction please?

One thing I am unsure of, is the okta account I am using doesn't currently have a matching admin user in craft, could this potentially be the problem? I would expect an unauthorized error instead.

[dsmrt]

If you got back to the CP and are seeing a 403, you may see this cause you don't have access to the cp with the user you just logged in with. See if this is the case (which it sounds like it is from the last point).

Also, see #52 on disabling the login buttons. We are actually working with Craft to put something in place here but it might take some time.

[J-Protz]

I do not see a 403, and the okta login does not seem to be creating a user at all. I tried to tie in to the saml events and log some data and I am just seeing nothing. I'm unsure if something was set up wrong on my side or OKTA. Meeting with the guy who set up the okta app today to double check it matches the documentation provided.

[dsmrt]

What are you seeing when you get back to the CP? Please be careful not to share sensitive info. Are you seeing an exception? Just the login page?

[J-Protz]

Sorry I dont know how I missed this reply until today - but I'm simply seeing nothing, just the login page. I have confirmed to the best of my ability that the okta side was set up correct. we had missed the certificate upload originally, but fixed this. It simply brings me back to the admin, and nothing happens. As if it's the first time loading the page.

I do have screenshots of the okta set up so I can confirm any questions, and obviously have access to my own admin set up. I am unsure as to what would be safe to share (this is just for local, so I assume most of it), but don't want to just dump all the screenshots here lol.

For reference however, we do have 2 providers being used. One is via front end, and the other is just for the CP. This is partially why I wonder if maybe I have set something up wrong. Especially when setting up the CP as it's own site, it didn't quite look exactly as it did in the docs.

[dsmrt]

Can you copy and paste the single sign on url for the app configured in Okta? You can disguise the host. This should point to the assertion consumer service url on the craft side.

If it’s sending you to the login page with no error or anything, there is probably something simple misconfigured.

[dsmrt]

Also, just to be sure you haven’t missed this, here is info on how to configure Okta: https://saml-sp.flipboxfactory.com/idps/okta.html#okta

[J-Protz]

I did use that link, but thank you!

Here is the SSO on okta's side. ~/admin/sso/login/786a1fcb-8c5c- 4fc3-886e-17d2339bb478

I am not familiar with what the assertion consumer service url is referring to, sorry very new to this.

[dsmrt]

Edit that sign on config by removing admin in the url. Having admin in there is forcing login, and ignoring the incoming message. Assertion consumer service url is where Okta will post the identity and auth info.

[J-Protz]

Okay - however my Assertion consumer service url in the control panel is ~/admin/sso/login/786a1fcb-8c5c-4fc3-886e-17d2339bb478 - how do I change this to remove the admin part? It is grayed out.

[J-Protz]

I changed the entity ID to /admin, is that potentially the problem here? I wanted it to point to the control panel. We already had a provider for the front end that pointed to services.<my-website>/, which is where the front end uses SSO, so I figured this should point to the CP.

[dsmrt]

What plugin version number are you using?

You can simply remove admin from the Sign-On input field in Okta. It doesn't need to change on the plugin side.

The Entity ID can be whatever you want. It's the unique id for your craft instance.

[J-Protz]

I am using 2.7.5.

I made a new provider to test out where the Assertion consumer service url was being generated from - it looks like it's based off the site url I choose. I am having this provider point to the control panel site I set up, which points to <my-site>/admin . This seems to follow what was in the documentation for the plugin seen here https://saml-sp.flipboxfactory.com/examples/multi-site-with-cp-login.html#solution

Do I need to change this so that the Assertion consumer service url does not have /admin?

[dsmrt]

I believe admin in the urls is fixed in later iterations of the plugin so you may want to look at upgrading. Not urgent but just know that it might fix some of the things you are seeing.

It's better to use the non-admin url for some of those /sso actions. You don't need to change anything on the craft side, just edit the url input on the Sign-on in Okta.

[J-Protz]

later versions must be for craft 4+, we're still on 3.9 with no available updates. I'll try that out and see how it goes, thank you.

[J-Protz]

I got this error when updating just the SSO login from okta.

Errors during validation: Destination in response "<my-site>/sso/login/786a1fcb-8c5c-4fc3-886e-17d2339bb478" does not match the expected destination "<my-site>/admin/sso/login/786a1fcb-8c5c-4fc3-886e-17d2339bb478"Recipient in SubjectConfirmationData ("<my-site>/sso/login/786a1fcb-8c5c-4fc3-886e-17d2339bb478") does not match the current destination ("<my-site>/admin/sso/login/786a1fcb-8c5c-4fc3-886e-17d2339bb478")

[dsmrt]

Ok ... I just realized we need to change the @web/admin/ on the site to just be the @web or to simply exclude the admin in the endpoints. Then, resave the service provider attached to that site in the SAML plugin. then the urls should match.

[J-Protz]

Okay - will this still separate the CP as it's own site though? I need to keep this separate from the front end, as the front end uses a different provider.

[J-Protz]

This did work - just not sure how this may effect separating front end form admin.

[dsmrt]

Is the hostname on the front end the same as the cp? If so, you can use the same craft site for both. From the plugin’s perspective, it only needs the site attachment for access to the base url.

[dsmrt]

Going to close this for now. Let me know if you have any other questions.