RE: [security-services] Re: Proposed Agenda for SSTC Call (May 18, 2010)

["Nguyenphu, Thinh (NSN - US/Irving)" <thinh.nguyenphu@nsn.com>]

Hi,

I agreed that AuthnRequest is better suit than Response.

Also, there is a use case where target IdP may required to initiate
account linking,  because the SAML federate pseudonum identifier may not
applicable to telco enviroment.  Thus, I prefer that the
<ManageSubjectRequest/Response><AddSubject> can be initiated by either
SP or target IdP for account linking during SSO authentication.

Thinh.

-----Original Message-----
From: ext Phil Hunt [mailto:phil.hunt@oracle.com] 
Sent: Friday, May 21, 2010 2:10 PM
To: Scott Cantor
Cc: 'Nate Klingenstein'; 'OASIS SSTC'
Subject: Re: [security-services] Re: Proposed Agenda for SSTC Call (May
18, 2010)

With regards to Tuesday's proposal, while the SP would prefer the  
Target to respond, I can see scenarios where the user might not be  
able to respond immediately. For example the Target may want to do an  
email confirmation verification.  That means that Step 8 may happen at  
a later time when using a <Response> flow.

If the TargetIDP is unable to respond with an immediate  
authentication, we would say that the process ends at step 7 and the  
SP may want to flag the account for deprovisioning. That might get  
triggered as a separate process once the user authenticates in the  
normal process via the TargetIDP, the SP could begin their de- 
provision process.

With regards to using AuthnRequest extended for step 6. I can see the  
reasoning, but I wonder about going back to the original proposal of a  
completely new operation <ManageSubjectRequest><AddSubject>.  However  
instead of the original proposal, I would change AddSubject to match  
the AuthNRequest plus needed extensions to address the issue of  
transferring a user. That way it has all of the advantages of the  
proven AuthnRequest/response profiles, but with the ability to control  
result flows a bit more.

There may be a couple advantages to a new operation:
* It keeps the operation obvious and distinct from authentication
* It would have the same "name" whether online or offline mode
* the operation is defined in a new namespace. So existing definitions  
are not touched/modified in potentially unexpected ways.

Finally in <ManageSubjectResponse>, we can also allow for different  
results.  Such as request complete/pending/incomplete.  The advantage  
being the Target IDP doesn't have to authenticate the user immediately  
and transfer its own <Response> back to the SP.

Using ManageSubjectRequest/Response may have an advantage because it  
doesn't require the Target IDP to complete an authentication when it  
might not be ready to do so while still allowing it to say "I've  
accepted your provisioning request".  The SP can then proceed with de- 
provisioning without worrying about a lost user or duplicate user  
problem.

Phil
phil.hunt@oracle.com




On 20-May-10, at 10:39 AM, Scott Cantor wrote:

>> I think one important item that was raised is that the SP would like
>> to get control back from the Target IDP regardless of success/
>> failure.
>
> I presumed so, that's why I thought it was probably better to try and
> compromise, and look at it as an AuthnRequest (which generally  
> mandates a
> response) rather than a Response (with some implication that another
> response is supposed to follow).
>
> -- Scott
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php