Re: [security-services] Using SAML Artifacts in the WSS SAML Token Profile

[Greg Whitehead <grw@trustgenix.com>]

On Jul 7, 2005, at 10:34 AM, Ron Monzillo wrote:

> Scott Cantor wrote:
>>> So, I'm looking at the latest SAML Token Profile document for the 
>>> WSS and though it worth mentioning that we consider documenting how 
>>> one would use a SAML artifact as a bearer token.
>> An issue to profile around is that artifacts in 2.0 were defined to be
>> protocol messages, not assertions. In this case, a samlp:Response,
>> presumably.
>> In a sense, this resembles the third-party AuthnRequest use case. 
>> You've got
>> a client (of whatever sort) who wants an assertion to give to a WSP, 
>> and
>> you're proposing this be done by artifact. In essence then, the 
>> client is
>> sending an request to the SAML authority for the token on behalf of 
>> the WSP,
>> but getting back the artifact representing the samlp:Response which 
>> the WSP
>> can be given to dereference.
>
> If you want to be able to use artifacts to secure SOAP messages, then 
> to be compatable with the WSS reference forms, it would seem that the 
> artifact, which i would view as a token reference, should be 
> encapsulated in an STR, as WSS differentiates references to tokens 
> from tokens.
>
> If this makes sens to others, we could add this ability to the STP. Of 
> course, if the client can transform the artifact into an assertion id,
> or a a uri query, the existing stp could accomodate the exchange of 
> the reference.

This is what I was thinking, but hadn't had time to comment on. Perhaps 
there's a new profile here that returns an assertion id instead of an 
artifact, or, more likely, an assertion id in a samlp:Response instead 
of an assertion.

There are lots of possibilities, so we need to keep the motivating use 
case in mind. If it's just privacy (in the third party use case), we 
already have a mechanism to encrypt the returned assertion. I think 
efficiency is the main motivator: the WSP to IdP channel may be higher 
bandwidth and provide channel security that eliminates the need to sign 
or encrypt the assertion.

-Greg

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