New Provision Profile for NSN/Oracle Attribute Mgmt Discussion

[Phil Hunt <phil.hunt@oracle.com>]

Thomas et al,

For tomorrow's conference call regarding the NSN/Oracle Attribute  
Management Agenda item:

Based on the last SSTC call, I took the liberty to re-work the  
provisioning scenario a bit based on everyones feedback.  The key to  
this, is the idea that the SP can issue an "unsolicited" <Response> as  
if it where an IDP directly to the Target IDP. This idea works for the  
front-channel only and addresses Scott's concern of maintaining/ 
transferring authentication (in the back-channel, we'll have to figure  
out some other method).

New flow:

1. User initiates a request to change or provision to a target IDP.
2-4. Before proceeding the SP performs a local authentication. This  
can be via SAML or some other method (e.g. LDAP).
5. The user indicates which IDP will be the new Target IDP
6. Based on SLA, the SP issues a SSO Provisioning request by issuing  
an IDP initiated request (unsolicited response). The response contains  
an attribute "RelayState" set to some value meaningful to the  
TargetIDP. In this case, RelayState might be set to "Provision" or  
"AddSubject".  Question: Should relayState value be profiled in the  
standard?
7. Having received an SSO request from the SP (now acting as IDP), the  
TargetIDP receives the request for the SP authenticated user and  
begins a process of creating a new account. Depending on the claims  
asserted by the SP, the Target IDP may need to merge the request with  
an existing account or create a new one.
8. The Target IDP returns with an authentication response of its own.
9. The SP accepts the new SSO token and "federates" the new token with  
its own information by associating the new NameID with the old profile.
10. Process complete

This approach does have the advantage that it fits within the current  
SAML 2 spec. The downside is that SP has to have IDP capability, and  
the SP and IDP have to agree on the provisioning request.

Would this work? Would the reverse mode (user starts at IDP) work as  
normal? Other issues?

Phil
phil.hunt@oracle.com