[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Stateless Conformity To SAML
Many of us consuming companies are working hard toward centralized identity management and therefore much prefer the "cause to be stored" approach over the "stored" approach. Also, many of us are very concervative when it comes to what mechanisms we will allow to write to our "stores". So I see us being cautious about turning on NameIDMapping functionality (although I expect we will see applicable scenarios as our deployment expands). So, if as Scott suggests as a deployer I have the option to negociate NameIDMapping out-of-band, and as the Core spec allows I can return a status of InvalidNameIDPolicy I can see this working for us. Of course, the negative is if NameIDMapping is MTI, and we chose not to use our vendor's implementation of that, we will still pay for it in the end. For those "cause to be stored" implementations, I see a bit vague separation of duty between the implementor responsibilities and deployer responsibilities. Also, how a functional NameIDMapping actually works on the backend in the "cause to be stored" environment may vary substantially. Seems an implementor needs to allow for the "stubbed out" NameIDMapping function, but at the same time I don't think we want to declare an implementation that is nothing more than a stub out (always returning an InvalidNameIDPolicy) to be declared conformant. Gee...so what exactly does the conformant implementor have to do in a "cause to be stored" solution when I won't let him/her write to my store? Suppose I just turn it off and the implementation always returns invalid. Appears in the "cause to be stored" environment the real functionality in NameIDMapping is outside of the spec. Mike -----Original Message----- From: Scott Cantor [mailto:email@example.com] Sent: Friday, July 30, 2004 1:28 PM To: 'Nick Ragouzis' Cc: 'SAML' Subject: RE: [security-services] Stateless Conformity To SAML > I like your approach of thinking from the other view. I think, > however, it's a bad idea to conceive of a 'general' SP that claims > support for name id mgt but that cannot/doesn't actually store (or > cause to be stored) persistent records. But "store" and "cause to be stored" are two fundamentally different implementation strategies that are (as I understood it) exactly what's at issue here. I can implement a largely stateless system that implements the protocol by "causing to be stored" the result of the messages. It's not up to me to make it happen, and I can't be blamed if the deployer refuses to implement the necessary write-back because he doesn't want to. Nor is that non-conformant, but rather a deployment choice (as long as I return an error when I'm asked to process the change and the write fails). > > Where we would run into trouble, I think, is if an implementation > > stores persistent records of user federations but doesn't support > > Name ID Management (federation termination in particular). > > Well put. This is one specific way in which the 'stateless' > implementation is problematic, and for which its designers would > probably have to rely on failure modes ... which would seem to shorten > the life of two important utilities of such a "device" > (speed and independence). But an implementation may well "support" persistent records of user identities (I prefer that to the term federations) without "storing" them. Does conformance need to distinguish such a case? From your previous note, it sounds like this was handled by making qualified statements of conformance, but that seems to underline what conformance is supposed to mean, and I didn't see any guidance in the SCR for how that works. -- Scott To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/security-services/members/l eave_workgroup.php.