SAML SSO en SCIM

[RedCellNL]

• SAML SSO: this allows your users to use a single sign-on (SSO) identity provider service to log in to the application, as opposed to using the default email + password.

• SCIM provisioning, also referred to as automated user management: SCIM provisioning allows organizations to use their identity provider service to automate how their users are added to and updated in the application. By definition, SCIM provisioning requires use of SAML SSO, but SAML SSO doesn't require SCIM.

Ik probeer te begrijpen waarom je SCIM gebruikt als je al SAML SSO hebt.

Als ik SAML SSO heb ingesteld voor een applicatie waardoor de medewerkers van mijn organisatie kunnen inloggen met hun username/password, waarom zou ik dan nog de identiteiten synchroniseren door middel van SCIM?

[oak3]

Ken de term SCIM niet, maar als ik het zo lees, dan interpreteer ik het als een synchronisatie tussen een HRM pakket en een Identity Provider.

[Tys]

SCIM regelt alleen dat er accounts gemaakt/aangepast worden in het doelsysteem. Afhankelijk van het systeem kan het zijn dat je daarmee ook kunt inloggen (met een wachtwoord voor die ene applicatie). Je kan met SCIM natuurlijk ook veel meer attributen meesturen die dan in dit doelsysteem worden opgeslagen. Dat kan vanalles zijn, van telefoonnummer, badge of personeelsnummers, etc.

Leg je daarnaast een SSO koppeling met dit doelsysteem dan kan je dus de situatie creëren dat je met 1 login (combinatie van gebruikersnaam en wachtwoord of andere factoren) in zowel je bron- als doelsysteem kunt inloggen.

[Voor 17% gewijzigd door Tys op 12-01-2022 20:59]

[darkrain]

Het gaat erom waar je je user management wilt doen, met SCIM (provisioning) is dat in de bron (AzureAd, Akto, ...) en met SSO is dat in de applicatie.

[RedCellNL]

Zoals ik het nu begrijp is bij SCIM het voordeel dat de gebruikers al bekend zijn in de applicatie voordat deze inlogt. Dit maakt het mogelijk om al permissies en licenties toe te kennen, welkom's mail te sturen etc.

Bij SAML is de gebruiker pas bekend als deze inlogt en zal je dus daarna nog licenties en permissies moeten instellen etc.

[darkrain]

RedCellNL schreef op donderdag 13 januari 2022 @ 10:42:
Zoals ik het nu begrijp is bij SCIM het voordeel dat de gebruikers al bekend zijn in de applicatie voordat deze inlogt. Dit maakt het mogelijk om al permissies en licenties toe te kennen, welkom's mail te sturen etc.

Bij SAML is de gebruiker pas bekend als deze inlogt en zal je dus daarna nog licenties en permissies moeten instellen etc.

Denk vooral ook aan wijzigingen en verwijderen van gebruikers... Dat zal met SCIM gaan, maar met SAML SSO niet.

[milo526]

Ik ben ontwikkelaar van een enterprise gerichte web applicatie, SSO en dat soort dingen zijn hier vrij gebruikelijk.
Onze applicatie ondersteunt SSO maar nog geen SCIM, de integratie van SCIM heb ik recentelijk onderzocht.

Gebruikers kunnen in onze applicatie zelf hun SSO koppeling regelen maar ze kunnen geen nieuwe accounts aanmaken, ook niet met SSO.
Een account kan alleen aangemaakt worden door iemand met voldoende rechten in de applicatie.
Ons voordeel voor SCIM is dat de account daarmee aangemaakt kunnen worden door de bron zoals al eerder aangegeven.
In plaats van een handmatige actie van de gebruiker kan een bron systeem nieuwe accounts aanmaken.

Zo zou je bijvoorbeeld een account voor iemand aan kunnen maken het moment dat deze persoon in een team wordt toegevoegd in bijv Azure Active Directory.

Het grootste voordeel voor ons is dus dat niet iedereen in een directory toegang moet hebben tot de applicatie, deze combinatie van SCIM en SSO kan authenticatie regelen via SSO voor een deel van de gebruikers in de directory.

[Korvaag]

RedCellNL schreef op donderdag 13 januari 2022 @ 10:42:
Bij SAML is de gebruiker pas bekend als deze inlogt en zal je dus daarna nog licenties en permissies moeten instellen etc.

SAML vereist in de regel dat de accounts al bekend zijn in het systeem. Je hebt een Identity Provider en Service Provider (IDP en SP). Authenticatie gebeurt bij de IDP en die stuurt vervolgens een assertion met daarin een identifier naar de SP. Deze SP wil deze identifier vervolgens matchen met een in het systeem aanwezig account. Door deze matching weet de SP over welke user het gaat. Denk aan mailadres [e-mail], accountnaam 'korvaag' of een (bijvoorbeeld) personeelsnummer.

Als je SAML wilt gebruiken zal je dus moeten zorgen dat de users via [een bepaald proces] aangemaakt worden bij de Service Provider. Dit kan op meerdere manieren (waaronder SCIM).

Eea is niet te verwarren met Just in Time provisioning (JIT). Dit maakt ook gebruik van SAML maar zorgt ervoor dat de accounts worden aangemaakt bij de Service Provider op moment van eerste inlog (dus.. just in time). Wat jij hierboven aangeeft doet vermoeden dat je JIT bedoelt maar dat is dus iets anders dan alleen SAML. JIT is iets wat niet zomaar door elke SP ondersteund wordt.

Dus:
SCIM: provisioning (CRUD, create, update delete*) en dit meestal aan de hand van IDU (indienst, doorstroom, uit dienst).
SAML: federatie. Accounts moeten hiervoor in de regel al bekend zijn in het aangesloten systeem (al dan niet via handmatige aanmaak, SCIM of andere vormen van koppelingen). Zonder accounts geen SSO.
JIT: SAML met automatische account aanmaak (is iets te zwart wit, maar voor nu even voldoende)

RedCellNL schreef op woensdag 12 januari 2022 @ 17:02:
SCIM provisioning, also referred to as automated user management: SCIM provisioning allows organizations to use their identity provider service to automate how their users are added to and updated in the application. By definition, SCIM provisioning requires use of SAML SSO, but SAML SSO doesn't require SCIM.

Dit is overigens niet per definitie waar. Mogelijk is dit specifiek voor de door jou gekozen SP het geval, maar ik kan prima via SCIM users provisionen naar (bijvoorbeeld) ServiceNow en die users via een activatieprocedure van een wachtwoord voorzien waardoor ze met username+password kunnen inloggen. Of dat ideaal is is even een andere discussie, maar het kan prima. Ik begrijp dan ook niet waar bovenstaand statement vandaan komt en voor zover ik weet is het domweg onwaar (mogelijk dus wel waar voor de betreffende service provider, maar niet vanuit SCIM zelf).

Let er trouwens wel even op dat persoonsinformatie verstrekken aan partijen aan regelgeving onderhevig is. Je kan niet zomaar zonder afspraken een complete HR-dump (of klantinformatie) aan een SAAS-boer geven. Dit even ter aanvulling.

* voor de volledigheid: SCIM ondersteunt meerdere operaties, maar ik pak even de essentie.

[Voor 31% gewijzigd door Korvaag op 16-01-2022 22:15]