Re: [OAUTH-WG] draft-ietf-oauth-saml2-bearer-10 question

It really depends on the situation - what other systems are available to
the client and the nature of the trust relationship between the client and
the AS.

As John said, a client could generate and self sign an assertion. This
likely works for well for client authentication via asymmetric keys.

WS-Trust/STS is the most typical (in my view anyway) way a client might get
an assertion to use for authorization. We've got a few customers doing it
that way.  I did a little demo a while back using WS-Trust but where the
assertion issuer acts as a broker of sorts in the transaction rather than
returning the assertion to the client:
https://www.pingidentity.com/blogs/pingtalk/index.cfm/2010/11/5/Securing-Mobile-for-Enterprise--SAML-OAuth-WSTrust-in-Action

ECP is possible but you are right that lack of support for it makes it
unlikely.

Various permutations of Web SSO are possible too.  The client might be a
SAML SP, for example, and get an assertion from an IDP that's suitable for
both SSO and use as a grant type. Although, in current practice, I don't
think IDP support for issuing such assertions is very good.

And there's nothing ruling out some kind of simple proprietary exchange
between the client and the assertion issuer.

On Thu, Apr 5, 2012 at 7:46 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

> Adam,
>
> It may be a self signed SAML assertion.
>
> That is likely the case where someone wanted to use asymmetric keys to
> authenticate to the Token Endpoint.
>
> I could see an STS used in some cases.
>
> ECP is a touch unlikely unless someone was super keen.
>
> The client could use a Web SSO profile to get a assertion for the user if
> you are using the Assertion profile for the Authorization endpoint.
>
> There is also a JWT token profile for assertions,  you knew I couldn't
> resist a plug:)
>
> John B.
> On 2012-04-05, at 10:35 PM, Lewis Adam-CAL022 wrote:
>
> Hi,****
> ** **
> Reading draft-ietf-oauth-saml2-bearer-10, it states:****
> ** **
> The process by which the client obtains the SAML Assertion, prior to****
>    exchanging it with the authorization server or using it for client****
>    authentication, is out of scope.****
> ** **
> Accepting that it’s out of scope from the draft, what are the realistic
> alternatives to obtaining the SAML assertion out of band?  WS-Trust
> provides a direct method to request a SAML assertion from a STS, and the
> SAML ECP profiles seems to allow this behavior, but it doesn’t seem like
> ECP is very well supported.  What other viable means are there from a
> client to directly request a SAML assertion from an assertion issuer?****
> ** **
> Tx!
> adam****
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>