Subject: [OAUTH-WG] Using SAML for authentication *and* as Authorization Grants

From: Pedro Felix <[email-masked]>
Date: Mon, 22 Jul 2013 14:39:20 +0100

Hi,

I'm considering a scenario where a Web App plays two roles:
1) As a SAML Service Provider/Relying Party, the Web App wants to
authenticate it's Users, via a third-party SAML Identity Provider
2) As an OAuth 2.0 Client, the Web App wants to use an API on the User's
behalf.

Both the IdP and the API (the Resource Server) belong to the same
organization.

Is it possible to use the *same* SAML assertion for both purposes, assuming
that both the SAML IdP and the OAuth AS are controlled by the same
organization. The sequence would be something like this:

1) The Client Web App uses the SAML protocol (e.g. Redirect Binding/POST
Binding) to request a SAML assertion from the IdP/AS.
2) The Client Web App uses the received SAML assertion to authenticate the
User, as defined by the SAML specs.
3) The Client Web App also uses the *same* received SAML assertion to
access the IdP/AS token endpoint and obtain an access token. For this, it
uses the SAML assertion as an authorization Grant (as defined by the "OAuth
SAML Assertion Profiles").

One possible problem that I've identified in this scenario is the Audience
restriction:

1) For the SAML assertion to be used by the Web App to authenticate the
User, then it's AudienceRestriction should include the Web App Audience
2) For the SAML assertion to be used as a Authorization Grant, then it's
AudienceRestriction should include the Authorization Server

However, the SAML assertion spec allow for multiple Audience elements on
the AudienceRestriction, allowing for the above scenario.

A complementary idea would be for the Authorization Server to check if the
OAuth client ID is also contained in the audience, before issuing an access
token.

Is this a legitimate use of the "OAuth SAML Assertion Profiles"? Are there
any security problems due to using the same SAML for both authentication
and authorization grant, given that the AudienceRestriction is properly
assigned and handled?

Thanks
Pedro

---

From: Brian Campbell <[email-masked]>
Date: Tue, 23 Jul 2013 08:14:12 -0600

Seems legitimate to me. In fact, initial versions of the draft sought to
simplify things by restricting the audience restriction and subject
confirmation to single elements but was expanded to allow for this kind of
scenario.

In my (somewhat limited) experience, however, support in SAML products for
producing assertions targeted at multiple audiences and with multiple
subject confirmations isn't very good. So while the standards allow for it,
you may run into issues trying to do this in practice. Maybe.

>From a security perspective I think it's okay. Though anytime you have a
bearer assertion targeted at multiple audiences, you do effectively allow
any of them to use the assertion. Which isn't always wrong but worth
considering. In this case though, I don't think that's an issue.

Another potential approach to consider for this particular case is to send
the OAuth access token with the SSO assertion (included as an attribute). I
believe some deployments are taking that approach today.

On Mon, Jul 22, 2013 at 7:39 AM, Pedro Felix <[email-masked]> wrote:

> Is it possible to use the *same* SAML assertion for both purposes,
> assuming that both the SAML IdP and the OAuth AS are controlled by the same
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Wed, 24 Jul 2013 02:31:13 +0000

Hi Pedro ... for what it's worth I am looking at something almost the same, except using JWT with OIDC.

1.       OIDC client (web app) requests an id_token from OIDC provider, including a request object specifying that the audience of the JWT id_token should include both the client_id and the AS in the audience field

2.       OIDC client (web app) uses the id_token received in the response in the OAuth JWT assertion profile as a grant to request additional OAuth access tokens

This was made possible relatively recently by updates to the draft-ietf-oauth-json-web-token spec and in conjunction with the OIDC messages spec.  The draft-ietf-oauth-json-web-token spec was updated to allow the audience claim to be an array of values.  OIDC allows for a request object to be communicated in the authorization request and hence specify the desired audiences.

I understand you're looking to use SAML and not OIDC, but I believe the flow is nearly identical.  As Brian mentions it might be more of an implementation issue than anything else.  But it seems acceptable from a security vantage anyway.

-adam

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Tuesday, July 23, 2013 9:14 AM
To: Pedro Felix
Cc: oauth
Subject: Re: [OAUTH-WG] Using SAML for authentication *and* as Authorization Grants

Seems legitimate to me. In fact, initial versions of the draft sought to simplify things by restricting the audience restriction and subject confirmation to single elements but was expanded to allow for this kind of scenario.

In my (somewhat limited) experience, however, support in SAML products for producing assertions targeted at multiple audiences and with multiple subject confirmations isn't very good. So while the standards allow for it, you may run into issues trying to do this in practice. Maybe.
>From a security perspective I think it's okay. Though anytime you have a bearer assertion targeted at multiple audiences, you do effectively allow any of them to use the assertion. Which isn't always wrong but worth considering. In this case though, I don't think that's an issue.
Another potential approach to consider for this particular case is to send the OAuth access token with the SSO assertion (included as an attribute). I believe some deployments are taking that approach today.

On Mon, Jul 22, 2013 at 7:39 AM, Pedro Felix <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

I'm considering a scenario where a Web App plays two roles:
1) As a SAML Service Provider/Relying Party, the Web App wants to authenticate it's Users, via a third-party SAML Identity Provider
2) As an OAuth 2.0 Client, the Web App wants to use an API on the User's behalf.

Both the IdP and the API (the Resource Server) belong to the same organization.

Is it possible to use the *same* SAML assertion for both purposes, assuming that both the SAML IdP and the OAuth AS are controlled by the same organization. The sequence would be something like this:

1) The Client Web App uses the SAML protocol (e.g. Redirect Binding/POST Binding) to request a SAML assertion from the IdP/AS.
2) The Client Web App uses the received SAML assertion to authenticate the User, as defined by the SAML specs.
3) The Client Web App also uses the *same* received SAML assertion to access the IdP/AS token endpoint and obtain an access token. For this, it uses the SAML assertion as an authorization Grant (as defined by the "OAuth SAML Assertion Profiles").

One possible problem that I've identified in this scenario is the Audience restriction:

1) For the SAML assertion to be used by the Web App to authenticate the User, then it's AudienceRestriction should include the Web App Audience
2) For the SAML assertion to be used as a Authorization Grant, then it's AudienceRestriction should include the Authorization Server

However, the SAML assertion spec allow for multiple Audience elements on the AudienceRestriction, allowing for the above scenario.

A complementary idea would be for the Authorization Server to check if the OAuth client ID is also contained in the audience, before issuing an access token.

Is this a legitimate use of the "OAuth SAML Assertion Profiles"? Are there any security problems due to using the same SAML for both authentication and authorization grant, given that the AudienceRestriction is properly assigned and handled?

Thanks
Pedro

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Manfred Steyer <[email-masked]>
Date: Wed, 24 Jul 2013 12:42:10 +0200

Hi Adam,

Thx for this interresting information. Did you consider, just using OIDC for both, authentication and authorization?

As the JWT-based id_token can contain self-defined claims and as the current spec gives us a way to exchange one token for another, which allows us for (SAML/WS-Trust-like) delegation-scenarios, I'm wondering, if I still need OAuth2-based authorization for enterprise-scenarios.

What do you think about this?

Wishes,
Manfred

Von meinem iPhone gesendet

Anfang der weitergeleiteten E‑Mail:

> Von: Lewis Adam-CAL022 <[email-masked]>
> Datum: 24. Juli 2013 04:31:13 MESZ
> An: Brian Campbell <[email-masked]>, Pedro Felix <[email-masked]>
> Kopie: oauth <[email-masked]>
> Betreff: Re: [OAUTH-WG] Using SAML for authentication *and* as Authorization	Grants
> 
> Hi Pedro … for what it’s worth I am looking at something almost the same, except using JWT with OIDC. 
>  
> I understand you’re looking to use SAML and not OIDC, but I believe the flow is nearly identical.  As Brian mentions it might be more of an implementation issue than anything else.  But it seems acceptable from a security vantage anyway.
>  
> -adam
>  
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 24 Jul 2013 15:04:47 +0100

Hi
On 24/07/13 03:31, Lewis Adam-CAL022 wrote:
> 1.OIDC client (web app) requests an id_token from OIDC provider,
> including a request object specifying that the audience of the JWT
> id_token should include both the client_id and the AS in the audience field
>
> 2.OIDC client (web app) uses the id_token received in the response in
> the OAuth JWT assertion profile as a grant to request additional OAuth
> access tokens
>
> This was made possible relatively recently by updates to the
> draft-ietf-oauth-json-web-token spec and in conjunction with the OIDC
> messages spec.  The draft-ietf-oauth-json-web-token spec was updated to
> allow the audience claim to be an array of values.  OIDC allows for a
> request object to be communicated in the authorization request and hence
> specify the desired audiences.
>
> I understand you’re looking to use SAML and not OIDC, but I believe the
> flow is nearly identical.  As Brian mentions it might be more of an
> implementation issue than anything else.  But it seems acceptable from a
> security vantage anyway.
>
That would interest us too.
What concerns me is this: a client web app is effectively impersonating 
a user to get a grant.

So the user is there but what happens to the user approving or denying 
the client application (as in a typical authorization code flow for 
example where a user is physically present), the user only knows that a 
log-on has happened ?

I guess a client application needs to tell the user upfront somehow ? Or 
the end user should go and pre-authorize a given client-application first ?

Cheers, Sergey

> -adam
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Brian Campbell
> *Sent:* Tuesday, July 23, 2013 9:14 AM
> *To:* Pedro Felix
> *Cc:* oauth
> *Subject:* Re: [OAUTH-WG] Using SAML for authentication *and* as
> Authorization Grants
>
> confirmation to single elements but was expanded to allow for this kind
> of scenario.
>
> In my (somewhat limited) experience, however, support in SAML products
> for producing assertions targeted at multiple audiences and with
> multiple subject confirmations isn't very good. So while the standards
> allow for it, you may run into issues trying to do this in practice. Maybe.
>
>  From a security perspective I think it's okay. Though anytime you have
> a bearer assertion targeted at multiple audiences, you do effectively
> allow any of them to use the assertion. Which isn't always wrong but
> worth considering. In this case though, I don't think that's an issue.
>
> Another potential approach to consider for this particular case is to
> send the OAuth access token with the SSO assertion (included as an
> attribute). I believe some deployments are taking that approach today.
>
>
> assuming that both the SAML IdP and the OAuth AS are controlled by the
> same organization. The sequence would be something like this:
>
> access the IdP/AS token endpoint and obtain an access token. For this,
> it uses the SAML assertion as an authorization Grant (as defined by the
> "OAuth SAML Assertion Profiles").
>
> A complementary idea would be for the Authorization Server to check if
> the OAuth client ID is also contained in the audience, before issuing an
> access token.
>
> Is this a legitimate use of the "OAuth SAML Assertion Profiles"? Are
> there any security problems due to using the same SAML for both
> authentication and authorization grant, given that the
> AudienceRestriction is properly assigned and handled?
>
> Thanks
>
> Pedro
>
>
> [email-masked] <mailto:[email-masked]>

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 24 Jul 2013 15:31:02 +0100

> What concerns me is this: a client web app is effectively impersonating
Well, I was wrong, the client app would still use its own credentials to 
request a grant using this SAML/JWT token representing the end user 
authentication. I'm just curious how the end user can be still kept in 
'control', the pre-authorization seems like the only option, but may be 
it is not true

Cheers, Sergey

---

From: John Bradley <[email-masked]>
Date: Wed, 24 Jul 2013 11:23:19 -0400

The SAML IdP issuing the assertion would need to collect the authorization.   Given that something approximating 0 SAML IdP do this out of the box you are going to wind up with something relatively custom.

In general if you want to collect consent use a regular code flow and have the AS use whatever federated Authentication you need.  
Having the client be the SAML SP (or possibly (ECP) in a web SSO flow is not ideal.

There is also no standard way of indicating the scopes granted in the SAML assertion, so in general you are limited to a fixed set.

If user consent is required the simple solution is to use the code flow, rather than the assertion flow.

If you are crossing security domains without additional user interaction then the assertion flow is more appropriate.

John B.

On 2013-07-24, at 10:31 AM, Sergey Beryozkin <[email-masked]> wrote:

> Well, I was wrong, the client app would still use its own credentials to request a grant using this SAML/JWT token representing the end user authentication. I'm just curious how the end user can be still kept in 'control', the pre-authorization seems like the only option, but may be it is not true
> 
> Cheers, Sergey
> 
>>

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 24 Jul 2013 21:50:35 +0100

Hi John
> If you are crossing security domains without additional user interaction then the assertion flow is more appropriate.
The comments are very helpful. In fact it made me think how critical it 
is to get the integration with the IDP which can authenticate & collect 
the authorization in one go if we simply can so the code flow.

Our product (not OAuth2 centric) ships a demo where OAuth2 Authorization 
Code Flow is implemented on top of a 'basic' SAML2 Web SSO, something I 
believe you suggested above as one of the options.

Now, as far as I can see the only difference between this approach and 
the one where IDP does both authentication and collects the 
authorization is that in the former case a user goes via 2 screens (1st 
- authenticate, 2nd - collect the authorization), in the latter - all is 
done in a single screen.

The latter option has its pluses in that the users would typically 
prefer to minimize an amount of UI work. In the former case - a user 
simply gets to the next screen.

My question is: as far as OAuth2 and IDP doing both authentication and 
the authorization are concerned, why it may be important to support this 
combination, in addition to a smoother UI experience ?

Is it to do with crossing the security domains ? You mention it but I 
don;t quite get it yet why the assertion flow would be better to say a 
'basic' SSO + the code flow alternative

Cheers, Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 24 Jul 2013 22:05:09 +0100

Hi John

Cheers, Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 25 Jul 2013 10:53:50 +0100

Sorry for a bit of duplication, might've sent one too many responses,
just would like to answer to my own question,

On 24/07/13 22:05, Sergey Beryozkin wrote:
>> The SAML IdP issuing the assertion would need to collect the
>> authorization.   Given that something approximating 0 SAML IdP do this
>> out of the box you are going to wind up with something relatively custom.
>>
>> In general if you want to collect consent use a regular code flow and
>> have the AS use whatever federated Authentication you need.
>> There is also no standard way of indicating the scopes granted in the
>> SAML assertion, so in general you are limited to a fixed set.
>>
>> If you are crossing security domains without additional user
>> interaction then the assertion flow is more appropriate.
>>
>

This is only a guess, but perhaps the assertion flow across the domains 
can help in that the authorization is collected only once at the initial 
log-in...
Anyway, this may be off-topic and apologies if the original 
question/topic has long been answered

Thanks, Sergey

>>> Well, I was wrong, the client app would still use its own credentials
>>> to request a grant using this SAML/JWT token representing the end
>>> user authentication. I'm just curious how the end user can be still
>>> kept in 'control', the pre-authorization seems like the only option,
>>> but may be it is not true
>>>
>>> Cheers, Sergey
>>>
>>>>