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] Use Cases




Beach, Michael C wrote on 11/29/2003, 3:05 PM:

 > I was envisioning the SPs would communicate with the IdP, not
 > necessarily with each other.

But if a group of SPs were to have a combined session that is 
independent of the IdP managed authentication session, the SPs would 
have to somehow indicate that they are part of the "session group" and 
events related to that group would need to be propagated to the members 
of the group, even if it was through a third party such as the IdP.  So 
it does create a path for the SPs to communicate with each other.

It does, also, introduce a problem in that the SPs would have to somehow 
indicate that they were part of the same session for the user.  If the 
SPs are closely related, they may fit the concept of "affiliations" that 
was introduced in ID-FF 1.2.  This would enable the SPs to work together 
for the user (with user opt-in, of course), but you would still need the
"SP group session" management stuff that doesn't exist in the current 
protocols.

 > Your comment about user financial sites is fundamentally what is
 > driving my interest in this.  I am looking for some way to provide
 > increased security at such sites while allowing them to participate
 > somehow in the SSO environment.  The challenge seems to be to find
 > some level of compromise that provides sensible, secure behavior from
 > a user perspective without undue technical complexity and overhead.

This can easily be done with the current protocols.

If the desire for increased security is from the SP, then SP can submit 
a request to the IdP with a "stronger" authentication context or with 
the ForceAuthn attribute set. The SP can also look at the 
AuthenticationInstant in the assertion and determine if it is recent 
enough for its security policy.

If the desire for increased security is from the user, they can instruct 
the IdP to require a particular level of authentication and/or 
credential confirmation for AuthnRequests from that SP.

The IdP, of course, can have policies that do the same.

What the current specs don't do is manage idle time.  However, John Kemp 
is working on a proposal where that could be implemented.

Conor




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