SAML and provisioning/deprovisioning
1,341 views
Skip to first unread message
Jason Haar
Jun 25, 2013, 6:31:08 AM6/25/13
to simple...@googlegroups.com
Hi there, not really SSP related, but...
I'm too lazy to go and read all available RFCs/etc, so can others say if
there is any hint SAML will standardize provisioning (ie auto creation
of accounts within an SP) and deprovisioning (ie deleting of accounts
within an SP) in the future? Every SP we've looked at has handled these
differently: none support deprovisioning (I know it would be not
trivial, but still), most seem to support auto-provisioning - except for
Google Apps(!!), and none of the commercial SPs we've set up even
support Single Logout. And shall I mention mobile apps (eg OAUTH). I
get the feeling the Cloud providers only nail SAML onto the side of
their apps in order to win major clients. Pretty depressing :-(
We've looked to SAML as a safe mechanism to share our internal Identity
Management system to Cloud resources, but these provisioning issues are
making me look endearingly back on LDAP (come back! All is forgiven! ;-)
Sorry in advance for my downer - I was a bit gutted to discover what
passes as "SAML support" by Google Apps. I expected more from them
--
Cheers
Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +1 408 481 8171
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
I'm too lazy to go and read all available RFCs/etc, so can others say if
there is any hint SAML will standardize provisioning (ie auto creation
of accounts within an SP) and deprovisioning (ie deleting of accounts
within an SP) in the future? Every SP we've looked at has handled these
differently: none support deprovisioning (I know it would be not
trivial, but still), most seem to support auto-provisioning - except for
Google Apps(!!), and none of the commercial SPs we've set up even
support Single Logout. And shall I mention mobile apps (eg OAUTH). I
get the feeling the Cloud providers only nail SAML onto the side of
their apps in order to win major clients. Pretty depressing :-(
We've looked to SAML as a safe mechanism to share our internal Identity
Management system to Cloud resources, but these provisioning issues are
making me look endearingly back on LDAP (come back! All is forgiven! ;-)
Sorry in advance for my downer - I was a bit gutted to discover what
passes as "SAML support" by Google Apps. I expected more from them
--
Cheers
Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +1 408 481 8171
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
Peter Schober
Jun 25, 2013, 7:15:17 AM6/25/13
to simple...@googlegroups.com
* Jason Haar <Jason...@trimble.com> [2013-06-25 12:31]:
provisioning services (vulgo SPML) project. So no, SAML won't
standardize provisioning. Even now the SAML specs cover many things
which many chose not to implementat. Your own example of SAML SLO
clearly shows that standardization by OASIS is not the issue (it's
been done 8 years ago).
What's available and doable with SAML wrt provisiiooning and
deprovisioning has been written up by Mikael Linden back in 2008, and
much of this stil stands, IMHO:
https://www.terena.org/mail-archives/tf-emc2/msg00813.html
You could also ask Niels @ SURFnet what was the outcome of their
activities in this regard (further down that same thread).
> Every SP we've looked at has handled these differently: none support
> deprovisioning (I know it would be not trivial, but still), most
> seem to support auto-provisioning - except for Google Apps(!!), and
> none of the commercial SPs we've set up even support Single
> Logout. And shall I mention mobile apps (eg OAUTH). I get the
> feeling the Cloud providers only nail SAML onto the side of their
> apps in order to win major clients. Pretty depressing :-(
Much to agree on here.
Auto-provisioning (also called "Just-in-time" provisiioning) based on
SAML attributes is pretty standard. The opposite not so much
("Just-in-case" provisioning, i.e., OOB processes for batches of
subjects and groups and permissions and whatnot, irrespective of
whether any of those subjects ever access the service; necessary
e.g. when you want to assign permissions to subjects before they ever
log in). SAML can't really help here.
SPML and now SCIM deal with these things. (SCIM 2.0 is currently being
developed at within IETF WGs, see http://datatracker.ietf.org/wg/scim/ )
-peter
> I'm too lazy to go and read all available RFCs/etc, so can others
> say if there is any hint SAML will standardize provisioning (ie auto
> creation of accounts within an SP) and deprovisioning (ie deleting
> of accounts within an SP) in the future?
OASIS security services (vulgo SAML) is independent from the OASIS
> say if there is any hint SAML will standardize provisioning (ie auto
> creation of accounts within an SP) and deprovisioning (ie deleting
> of accounts within an SP) in the future?
provisioning services (vulgo SPML) project. So no, SAML won't
standardize provisioning. Even now the SAML specs cover many things
which many chose not to implementat. Your own example of SAML SLO
clearly shows that standardization by OASIS is not the issue (it's
been done 8 years ago).
What's available and doable with SAML wrt provisiiooning and
deprovisioning has been written up by Mikael Linden back in 2008, and
much of this stil stands, IMHO:
https://www.terena.org/mail-archives/tf-emc2/msg00813.html
You could also ask Niels @ SURFnet what was the outcome of their
activities in this regard (further down that same thread).
> Every SP we've looked at has handled these differently: none support
> deprovisioning (I know it would be not trivial, but still), most
> seem to support auto-provisioning - except for Google Apps(!!), and
> none of the commercial SPs we've set up even support Single
> Logout. And shall I mention mobile apps (eg OAUTH). I get the
> feeling the Cloud providers only nail SAML onto the side of their
> apps in order to win major clients. Pretty depressing :-(
Auto-provisioning (also called "Just-in-time" provisiioning) based on
SAML attributes is pretty standard. The opposite not so much
("Just-in-case" provisioning, i.e., OOB processes for batches of
subjects and groups and permissions and whatnot, irrespective of
whether any of those subjects ever access the service; necessary
e.g. when you want to assign permissions to subjects before they ever
log in). SAML can't really help here.
SPML and now SCIM deal with these things. (SCIM 2.0 is currently being
developed at within IETF WGs, see http://datatracker.ietf.org/wg/scim/ )
-peter
Tom Scavo
Jun 25, 2013, 7:23:14 AM6/25/13
to simpleSAMLphp
On Tue, Jun 25, 2013 at 6:31 AM, Jason Haar <Jason...@trimble.com> wrote:
>
> I'm too lazy to go and read all available RFCs/etc, so can others say if
> there is any hint SAML will standardize provisioning (ie auto creation
> of accounts within an SP) and deprovisioning (ie deleting of accounts
> within an SP) in the future?
SAML is an OASIS spec (not IETF) but in any case there is no such
>
> I'm too lazy to go and read all available RFCs/etc, so can others say if
> there is any hint SAML will standardize provisioning (ie auto creation
> of accounts within an SP) and deprovisioning (ie deleting of accounts
> within an SP) in the future?
thing in the pipeline AFAIK.
> Every SP we've looked at has handled these
> differently: none support deprovisioning (I know it would be not
> trivial, but still), most seem to support auto-provisioning - except for
> Google Apps(!!)
> and none of the commercial SPs we've set up even
> support Single Logout.
> And shall I mention mobile apps (eg OAUTH). I
> get the feeling the Cloud providers only nail SAML onto the side of
> their apps in order to win major clients. Pretty depressing :-(
"SAML is dead" after all!
> We've looked to SAML as a safe mechanism to share our internal Identity
> Management system to Cloud resources, but these provisioning issues are
> making me look endearingly back on LDAP (come back! All is forgiven! ;-)
http://tools.ietf.org/wg/scim/
There's even a "SCIM Profile For Enhancing Just-In-Time Provisioning"
that mentions SAML as an adjunct. You should take a look at that.
Tom
Nate Klingenstein
Jun 25, 2013, 1:52:35 PM6/25/13
to <simplesamlphp@googlegroups.com>
> SAML is an OASIS spec (not IETF) but in any case there is no such
> thing in the pipeline AFAIK.
The Change-Notify specification that Oracle and Nokia-Siemens worked on had this sort of a use case.
> thing in the pipeline AFAIK.
http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml2-notify-protocol/v1.0/csprd01/sstc-saml2-notify-protocol-v1.0-csprd01.html
I have no idea what deployment looks like.
There are serious issues with the SCIM specification too, obviously.
My personal opinion is that provisioning is not a problem for which there is a good general solution. Any protocol to support provisioning generically will be at best an ill-fitting circle that lassos a few use cases. Everything else will be customizable and extensible, which is basically where we're at today.
I wish it at least used actually qualified names.
chris phillips
Jun 25, 2013, 3:10:16 PM6/25/13
to simple...@googlegroups.com
A challenge that SCIM attempts to deal with is establishing what primitives would look like in provisioning and an attempt at nailing 80% of the 'regular' schema pieces knowing that the 20% of bespoke work on schema needs to be encapsulated too. Rather than run vendor XYZ 'connector' for CRUD operations, just use SCIM CRUD operations.
SCIM purposely stays at arms length from endpoint security conversation between endpoints (1:1, 1:N, N:M) because the moment you do so is the moment you go from a pure primitive/attribute/schema conversation to one getting heavily decorated with a control infrastructure to apply <insert your favourite policy here>.
The easiest out with least effort (so far) is SAML+JIT provisioning via attribute presence+ living with the downsides.
If you want to be more eloquent, you can do SAML+JIT+sync
Downsides are:
- you never get the deprovision event, the user just never returns to the Service Provider
- you never get a data update event, until the user logs in (just like the confluence connector today BTW)
- you never get group updates, until the user logs in.
There is a work item talking about SCIM+SAML and I feel that it boils down to schema and somehow reflecting SCIM primitives in SAML cleverly, leveraging SAML+Change Notify functionality that few sites implement, or maybe simply registering OIDs for SCIM schema for the bits that sit outside inetOrgPerson and eduPerson as SCIM schema has more fidelity about attribute data.
The loose end on that one are complex attributes in SCIM. How can you/should you represent complex user defined attributes of arbitrary depth in SAML? Using XPATH-ish notation in SAML? It gets messy fast.
If you want to know more, check out the spec and join the sc...@ietf.org list. There's a webex call tomorrow too:
Nate, on the qualified names, are you saying OIDS for the names or matching existing attributes?
HTH
Chris.
Nate Klingenstein
Jun 25, 2013, 8:32:46 PM6/25/13
to <simplesamlphp@googlegroups.com>
Chris,
> The loose end on that one are complex attributes in SCIM. How can you/should you represent complex user defined attributes of arbitrary depth in SAML? Using XPATH-ish notation in SAML? It gets messy fast.
I haven't found many deployments that want to use structured XML attributes, but yes, there is no clean way to express it if you do. You can always just cram it into a string with a unique name, which is what most seem to do.
> Nate, on the qualified names, are you saying OIDS for the names or matching existing attributes?
http://tools.ietf.org/html/draft-ietf-scim-core-schema-01
Something unique and well-defined. I might just be missing it, but things like "id" and "userName" appear to be mandatory and unscoped with no description of how they're made unique or what valid formats/characters/etc. are. I've spent a long time trying to get vendors to use unique attribute names, or at least names that aren't going to collide...
I also have no idea how to meet some of the requirements, like:
"This identifier MUST be unique across the Service Consumer's entire set of Users." -- how would the "Service Provider", which I guess is what we think of as an identity provider, be able to guarantee that?
I could go on, and I wish I had time to contribute properly. But I think provisioning is just a really hard problem.
Hope this clarifies,
Nate.
> The loose end on that one are complex attributes in SCIM. How can you/should you represent complex user defined attributes of arbitrary depth in SAML? Using XPATH-ish notation in SAML? It gets messy fast.
> Nate, on the qualified names, are you saying OIDS for the names or matching existing attributes?
Something unique and well-defined. I might just be missing it, but things like "id" and "userName" appear to be mandatory and unscoped with no description of how they're made unique or what valid formats/characters/etc. are. I've spent a long time trying to get vendors to use unique attribute names, or at least names that aren't going to collide...
I also have no idea how to meet some of the requirements, like:
"This identifier MUST be unique across the Service Consumer's entire set of Users." -- how would the "Service Provider", which I guess is what we think of as an identity provider, be able to guarantee that?
I could go on, and I wish I had time to contribute properly. But I think provisioning is just a really hard problem.
Hope this clarifies,
Nate.
Reply all
Reply to author
Forward
0 new messages