Subject: Re: [security-services] Stateless Conformity To SAML
Nothing requires that the Name ID Management service endpoints be co-located with the SSO consumer endpoints, so I don't see that deploying a read-only SAML consumer at an enforcement point on the edge of the network precludes deploying a Name ID Management capability somewhere else. In any case, my only point was that it seems fair to require that systems that ARE stateful (ie persistently record name identifiers received via SSO assertions, aka record federations in-band) also support Name ID Management. Systems that are stateless, or that require name identifier mappings (aka federations) to be managed out-of-band, need not support Name ID Management. -Greg On Jul 30, 2004, at 3:16 PM, Scott Cantor wrote: >> Perhaps you could briefly explain how your federation products >> would work as "enforcement points" that would consume (or >> produce) SAMLv2.0 name id mgt without the ability to "cause to be >> stored" updates to that federation (or alternately, identity >> network failure modes as route-arounds)? Take, for example, the >> cases that Greg raised and to which I was responding in this >> message. > > They wouldn't, but that's the point. Not everybody is pursuing the > approach > to managing identifiers in-band that Liberty (and now SAML) provides. > As > Prateek noted, transactional integrity and reliability are often pretty > important, and neither SOAP nor the browser bindings provide it. > > Such enforcement points consume identifiers and may be reading data > sources > that are synchronized to these out of band mechanisms. > > Liberty *deployments* are free to do this (they don't have to use the > profiles) but Liberty IdP/SP implementations are not free to do this > exclusively. > > -- 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/leave_workgroup.php.