OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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.


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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]