SAML - when creating new users, how do I get essential fields?

Question

(I posted this on security exchange a couple days ago, but no answers yet, so bringing it here.)

My company runs a saas product; as we move into enterprise customers, we're getting more and more requests for SSO.

I understand the SAML workflow for authentication, and roughly how we'd implement it. I also get that we could allow companies to create new users via SAML, i.e. a user which is authenticated by the identity provider can be created when they hit our system.

There's a few aspects of this that my google-fu is defeating me on.

1) How do I get necessary metadata in the new-user flow? E.g. to get a user up and running in our system, we need to know what team they're on, a specific third party id, and a couple of other things. Presumably this same workflow can take care of edits to users, e.g. "this user has moved to new team Y" is handled just by team_id being changed on an authenticated request from the identity provider.

2) How do I deal with deactivation? We sell our customers N seats at a time; it's unsatisfactory to say "if I haven't seen a user in Y weeks then consider them deactivated".

3) Some of our existing customers use Azure, Ping, Okta to manage their users (and want to continue doing so). All of them can talk SAML, so for authentication we're good if we implement SAML auth. However, how would they set up their systems to require those specific fields to be supplied?

4) Finally (maybe covered already by answers to above) what's the incentive for me, an application provider, to sign up with Okta, Ping, etc?

Thanks

Answer 1

These things are normally started by creating a contractual association between the provider (SP) and the customer (IdP), i.e. the IdP paying money to the SP for the service. Once that's out of the way, you can set up the attribute requirements.

Lots of SPs use eduPerson attributes for provisioning. e.g.

what team they're on

could be done with eduPersonScopedAffiliation:

team_name@company.com

The scope part company.com would be specific to that customer.

a specific third party id

could be done with eduPersonUniqueId:

49832387

or you can use an opaque identifer such as eduPersonTargetedID. The idea is that this unique id is your 'handle' from which to hang the user's personal information (subject to laws such as GDPR etc). So you can use the unique id to load the existing metadata you have for that id and manage any changes, to team_id etc.

a couple of other things

you can use any of the eduPerson attributes or negotiate custom ones. All IdPs can release any attribute once configured.

How do I deal with deactivation?

You can't, using SAML. It's an authentication/authorization flow so you only interact with a user when they interact with you. Perhaps this process of deactivation could be part of the initial contract. The customer agrees to send you the unique ids of anyone who has left (to save them seat money?). Or if the client company leaves, delete all data associated with their scope.

how would they set up their systems to require those specific fields to be supplied?

that's up to them. Once you have negotiated the release of the required attrbibutes from each customer's IdP, the customer will set up their end and configure the release. It's not your problem. If they use SAML, they should be able to configure their IdP to release what you require. All you care about is the arrival of the required attributes. So will the customer as without them there is no access to the contractually protected service.

what's the incentive for me, an application provider, to sign up with Okta, Ping, etc?

I think most people who use these services want to run IdPs so you'd just consume the SAML metadata they provide. You need to run an SP so you could just use the I2 SP and customise it to your environment.

Answer 2

SAML is an autentication protocol not a provisioning one.

Have a look at SCIM.

e.g. Azure AD can authenticate users with SAML but has a different provisioning flow.