FW: [security-services] W-5: SSO Profile Enhancements (Part 1)

["Mishra, Prateek" <pmishra@netegrity.com>]

Scott,


As I understand the materials in ID-FF 1.2 Protocols and Bindings, both 
AuthNRequest and AuthNrequest are derived from samlp:RequestAbstractType
and samlp:Response type. In other words, this material is already
in the form of an extension to the SAML protocol family and could
"simply [be] viewed as SAML protocol"

My guess is that this could be integrated with the SOAP binding as found in
SAML 1.1. I don't see too much difficulty in this space.

Regarding the artifact and POST profiles, first, as discussed in this
thread, this topic should be dealt separately from the request-response
foundations. Viewing them as a particular 
(peculiar?) implementation of the AuthNrequest-AuthNresponse pair works for
me.



- prateek



-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Friday, January 23, 2004 1:22 PM
To: 'Mishra, Prateek'; security-services@lists.oasis-open.org
Subject: RE: [security-services] W-5: SSO Profile Enhancements (Part 1)

> 1. The SSTC continue to work with the structure given in the ID-FF 1.2
> materials. In other words, separate generic flows and schema extensions
> required to support Web SSO and federation from specific technology
> realizations.  

Yes, it's been my hope that we could generalize things by describing new
"bindings" for the SAML request/response protocol that would be bound to a
browser and URLs as the transport instead of SOAP. This models the use of
redirection to carry messages in both ID-FF and SAML, but permits (nearly)
any protocol message to be carried that way when practical.

I also think we should try and unify the processing rules and content
between the artifact and POST profiles as much as we can, which I think is
very achievable if the artifact request is simply viewed as an alternate
binding for returning the Response message to the destination site when the
browser "binding" is used. This requires some respinning of what an artifact
really is, but I don't think that's insurmountable.

I think the end result will be similar in form if perhaps not in
presentation, but will be easier to understand and to extend to new use
cases. As an example I noted before, if the AuthnRequest and Response
messages are simply viewed as SAML protocol, then we already have a SOAP
binding, and a profile for SOAP-speaking clients and providers falls out
from that fairly readily.

-- Scott