Configuring Single Sign On (SSO) with SAML

[robin]

Single Sign On is a convenient way for users to log into multiple services without needing to enter their user name and password for each service.

SnapLogic supports Single Sign On (SSO) through the Security Assertion Markup Language (SAML) standard. If you are using an SAML2 Identity Provider (IdP) to perform SAML authentication, then you can configure your SnapLogic organization to authenticate users against your IdP.

Learn how to configure your organization for Single Sign On in the SnapLogic Product Documentation.

[christwr]

I’m curious about SSO (Okta) when having multiple organizations…

We have three organizations (dev, test, and prod) which would have different lists of users. Maybe some of the same users across different the orgs, but maybe not all users from test would be in prod for example.

In the SnapLogic SSO configuration, I can implement the same SSO metadata file (prod for example) in all of the orgs, but then it’s checking against the same user list in Okta (prefer to have different user lists for each org) and wants the users to all exist in the prod org in the SnapLogic side. Otherwise we get SSO sign-on errors like:

Single Sing On authentication failed. User XXX is not a member of the organization ‘XXX’ (prod)

Or I can configure each SnapLogic org with it’s own SSO metadata file (still Okta), which would validate against the environment-specific user list in Okta and let each org have it’s own users defines in SnapLogic. But then for users who exist in more than just one of the organizations, we get SSO sign-on errors like:

Single Sign On authentication failed. SSO login cannot be used for users that are members of orgs that have different identity providers

So, how do I go about having different lists of users in each organization (maybe some same users in multiple orgs) without the errors mentioned above? For example, I will have some users in both test and prod, and some users in test but not in prod.

I assume I’m just missing something… Thoughts?

[mikeandrews]

hi christwr.

Not sure on the SL side but I believe in Okta you can set up a higher level org than imports/trusts one or more child orgs - you’d still maintain autonomy of users/groups etc in dev/test/prod but you could set up any cross-org apps to use this parent okta org as the point of trust and where you configure the okta application. this says

members of orgs with different IdPs will not be able to login via SSO. For example, if “joe@example.com” is a member of the SnapLogic orgs Example-X and Example-Y, he cannot log in through SSO if these orgs are configured with different IdPs.

so maybe if you set up the ‘master’ okta org this could act as your single IdP?

nb this is an Okta feature, other SSO providers dont offer this. We used to use Microsoft ACS (Access Control Service) as our federation broker but that is deprecated.

on the SL side you’d have to be careful about not allowing or assigning ‘production’ rights to users from the dev org… i think the child okta org can be exposed as a claim which might be usable inside SL? sorry thats a lot of conjecture and not very specific 😉

we havent set up SSO on our SL org yet (ADFS3) so am not sure of the possible rules and mappings we can apply via the SAML token and claims.