Configuring Single Sign On (SSO) with SAML
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 th...
Forum Discussion
Those Binary Header settings on the CSV Formatter seem strange. The snap is going to create one binary CSV document containing the ALL of the documents from the script output. So you can’t really set headers containing detail-level values. The binary header is more for stuff like content-type, content-location, etc. Doesn’t explain why it’s creating the output you observed, but might be worth just taking those out and seeing if it makes any difference.
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.
