Subject: [OAUTH-WG] SAML-like ActAs

From: "Manfred Steyer" <[email-masked]>
Date: Fri, 19 Jul 2013 12:15:47 +0200

Hi,

are there plans for supporting delegation-styles like ActAs or OnBehalfOf in
SAML?

If this was possible, a resource server could delegate a subset of the
delegated rights to another resource server. This could be a very important
thing, when one wants to use OAuth 2 within an enterprise-environment. 

I know, that OAuth 2 has been created for web-scenarios, but it's a fact
that OAuth 2 is used as a "REST-friedly" alternative to WS-* in the area of
service-security. 

Would it be the right way, to define an Extension Grants for such a
scenario?

Wishes,

Manfred

---

From: Justin Richer <[email-masked]>
Date: Fri, 19 Jul 2013 10:52:22 -0400

While I won't profess to be proficient at SAML, I can say that there 
have been a couple tries at defining a "chained delegation" grant extension:

http://tools.ietf.org/html/draft-richer-oauth-chain-00

http://tools.ietf.org/html/draft-hunt-oauth-chain-01

We've deployed the first one with a couple projects here and it works 
pretty well, especially with structured tokens and token introspection. 
It might not be a drop-in replacement, but many times looking at a SAML 
problem with OAuth requires rethinking and reframing the problem a bit, 
just like JSON isn't going to be a drop-in replacement for XML.

  -- Justin

On 07/19/2013 06:15 AM, Manfred Steyer wrote:
>
> Hi,
>
> are there plans for supporting delegation-styles like ActAs or 
> OnBehalfOf in SAML?
>
> delegated rights to another resource server. This could be a very 
> important thing, when one wants to use OAuth 2 within an 
> enterprise-environment.
>
> I know, that OAuth 2 has been created for web-scenarios, but it's a 
> fact that OAuth 2 is used as a "REST-friedly" alternative to WS-* in 
> the area of service-security.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Fri, 19 Jul 2013 11:35:53 -0400

Yes, the drafts are expired, but that's largely because there hasn't 
been enough traction in the IETF to push them forward yet. It doesn't 
mean that the mechanisms in them don't work though, and if we can get 
more support behind them (which includes implementations) we can 
eventually put them into full fledged standards.

  -- Justin

On 07/19/2013 11:24 AM, Manfred Steyer wrote:
>
> Hi Justin,
>
> thanks for this answer. Those drafts are really what I was looking for 
> (I've discovered them yesterday), but unfortunately, it seems like 
> they are expired and it doesn't seem that there is a replacement that 
> is generally accepted.
>
> Do I see that right?
>
> Perhaps OpenId Connect gives us a generally accepted way to do such 
> things in a "REST-friedly" way. While the OpenId Connect Specs [1] 
> doesn't explicitly mention delegation-scenarios like ActAs in SAML it 
> seems to respect such scenarios in a subtle way by the use of the 
> id_token_hint-parameter, which allows to authenticate using an 
> existing token. In addition to that, it allows for scenarios where the 
> requestor of the token isn't the audience by specifying the azp claim. 
> And one can include custom claims, which can be used for authorisation.
>
> What do you think about that?
>
> Wishes,
>
> Manfred
>
> [1] http://openid.net/specs/openid-connect-basic-1_0.html
>
> *Von:*Justin Richer [mailto:[email-masked]]
> *Gesendet:* Freitag, 19. Juli 2013 16:52
> *An:* Manfred Steyer
> *Cc:* [email-masked]
> *Betreff:* Re: [OAUTH-WG] SAML-like ActAs
>
> pretty well, especially with structured tokens and token 
> introspection. It might not be a drop-in replacement, but many times 
> looking at a SAML problem with OAuth requires rethinking and reframing 
> the problem a bit, just like JSON isn't going to be a drop-in 
> replacement for XML.
>
>  -- Justin
>
>     If this was possible, a resource server could delegate a subset of
>     the delegated rights to another resource server. This could be a
>     very important thing, when one wants to use OAuth 2 within an
>     enterprise-environment.
>
>     I know, that OAuth 2 has been created for web-scenarios, but it's
>     a fact that OAuth 2 is used as a "REST-friedly" alternative to
>     WS-* in the area of service-security.
>
>     Would it be the right way, to define an Extension Grants for such
>     a scenario?
>
>     Wishes,
>
>     Manfred
>
>
>
>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: Prateek Mishra <[email-masked]>
Date: Fri, 19 Jul 2013 12:02:38 -0400

Hi Manfred,

This is an area of interest to us and we have done some profiling in our 
implementation.

Generally speaking, we work with the assertion profiles as a starting 
point. They allow for WS-Trust
like token exchanges and (implicitly) support ActAs or OnBehalfOf. But 
they do need additional profiling
to offer genuine interoperability in this area.

https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/  
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/    
https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/

What use-cases do you have in mind? I am not sure I follow what you mean 
by "a resource server could delegate a subset of the delegated rights to 
another resource server".

- prateek

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 19 Jul 2013 16:12:04 +0000

You can accomplish the ActAs semantics with Assertions profile, while a bit clumsy the basics are in place, the only issue is that you don't have any way to indicate the formal semantics

From: [email-masked] [mailto:[email-masked]] On Behalf Of Prateek Mishra
Sent: Friday, July 19, 2013 9:03 AM
To: Manfred Steyer
Cc: [email-masked]
Subject: Re: [OAUTH-WG] SAML-like ActAs

Hi Manfred,

This is an area of interest to us and we have done some profiling in our implementation.

Generally speaking, we work with the assertion profiles as a starting point. They allow for WS-Trust
like token exchanges and (implicitly) support ActAs or OnBehalfOf.  But they do need additional profiling
to offer genuine interoperability in this area.

What use-cases do you have in mind? I am not sure I follow what you mean by "a resource server could delegate a subset of the delegated rights to another resource server".

- prateek

Hi,

are there plans for supporting delegation-styles like ActAs or OnBehalfOf in SAML?

If this was possible, a resource server could delegate a subset of the delegated rights to another resource server. This could be a very important thing, when one wants to use OAuth 2 within an enterprise-environment.

I know, that OAuth 2 has been created for web-scenarios, but it's a fact that OAuth 2 is used as a "REST-friedly" alternative to WS-* in the area of service-security.

Would it be the right way, to define an Extension Grants for such a scenario?

Wishes,
Manfred

OAuth mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Manfred Steyer" <[email-masked]>
Date: Fri, 19 Jul 2013 18:40:37 +0200

Hi Prateek,

thouse drafts go in the right direction, but as you mention, they need
additional profiling. 

The drafts, that Justin mentioned in the mail before (see [1] and [2]), seem
to do exactly that.

With "a resource server could delegate a subset of the delegated rights to
another resource server" I mean the scenario, that is addressed by [1]:

1.      Client gets an OAuth-2-Token T1 with the scope A, B, C

2.      Client uses T1 to call service A (which expects a token with the
scope A)

3.      Service A exchanges T1 for another token T2 containing just the
scope B (which is a real subset of the scope of T1)

4.      Service A uses T2 to access service B (which expects a token with
the scope B)

[1] goes one step further by allowing claim-mapping, so that the holder of a
token can exchange it for a other token with another scope. This would, for
instance, allow for a delegation trough the boundary of a security-domain,
case you could introduce rules like: Everyone, that has the scope Projekt-A
at company X gets the scope Plans-for-A at company Y.

[1]  <http://tools.ietf.org/html/draft-richer-oauth-chain-00>
http://tools.ietf.org/html/draft-richer-oauth-chain-00
[2]  <http://tools.ietf.org/html/draft-hunt-oauth-chain-01>
http://tools.ietf.org/html/draft-hunt-oauth-chain-01

As mentioned, [1] and [2] are expired, but in my opinion they are just
perfect for doing such scenarios with OAuth 2 and so they would deserve to
become a standards.

What can we do, to achieve this goal?

In addition to that, OpenId Connect, which bases on OAuth 2, could provide
such scenarios, as mentioned in the mail before.

Wishes,

Manfred

 

Von: Prateek Mishra [mailto:[email-masked]] 
Gesendet: Freitag, 19. Juli 2013 18:03
An: Manfred Steyer
Cc:  <mailto:[email-masked]> [email-masked]
Betreff: Re: [OAUTH-WG] SAML-like ActAs

Hi Manfred,

Generally speaking, we work with the assertion profiles as a starting point.
They allow for WS-Trust
like token exchanges and (implicitly) support ActAs or OnBehalfOf.  But they
do need additional profiling
to offer genuine interoperability in this area.

What use-cases do you have in mind? I am not sure I follow what you mean by
"a resource server could delegate a subset of the delegated rights to
another resource server".

- prateek

Hi,

Wishes,

Manfred

---

From: "Manfred Steyer" <[email-masked]>
Date: Fri, 19 Jul 2013 18:40:49 +0200

Hi Nadalin,

that means, that I would use an existing OAuth-2-Token as the assertion for
requesting another OAuth-2-Token, right?

Section 5.2.  "General Assertion Format and Processing Rules" of this draft
says, that the assertion has to contain an Issuer as well as an audience.
The OAuth-2-Token doesn't have such fields by definition, but one can argue,
that it is associated with an issuer (= auth-server) as well with a scope,
which could be seen as the audience in this case.

Am I right?

Wishes,

Manfred

Von: Anthony Nadalin [mailto:[email-masked]] 
Gesendet: Freitag, 19. Juli 2013 18:12
An: Prateek Mishra; Manfred Steyer
Cc:  <mailto:[email-masked]> [email-masked]
Betreff: RE: [OAUTH-WG] SAML-like ActAs

You can accomplish the ActAs semantics with Assertions profile, while a bit
clumsy the basics are in place, the only issue is that you don't have any
way to indicate the formal semantics

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Prateek Mishra
Sent: Friday, July 19, 2013 9:03 AM
To: Manfred Steyer
Cc: [email-masked]
Subject: Re: [OAUTH-WG] SAML-like ActAs

Hi Manfred,

- prateek

Hi,

Wishes,

Manfred

---

From: Brian Campbell <[email-masked]>
Date: Fri, 19 Jul 2013 13:32:19 -0600

FWIW, the 3 assertion documents are more targeted at cross domain type use
cases. For example, assuming a trust (and liklely legal) relationship is in
place, some corporate system acting as the client can trade a SAML token in
at the AS of a SaaS provider for an OAuth access token, which can then be
used to do things at the SaaS's RSs 'on behalf' of the subject identified
in the assertion. That's not the only way it could be deployed but was one
of the main motivating use cases.

General access tokens are undefined so one could structure them in a way
that works with one of the assertion grants.

On Fri, Jul 19, 2013 at 10:40 AM, Manfred Steyer <[email-masked]>wrote:

> Hi Nadalin,****
>
> ** **
>
> that means, that I would use an existing OAuth-2-Token as the assertion
> for requesting another OAuth-2-Token, right?****
>
> ** **
>
> Section 5.2.  „General Assertion Format and Processing Rules” of this
> draft says, that the assertion has to contain an Issuer as well as an
> audience. The OAuth-2-Token doesn’t have such fields by definition, but one
> can argue, that it is associated with an issuer (= auth-server) as well
> with a scope, which could be seen as the audience in this case.****
>
> ** **
>
> Am I right?****
>
> ** **
>
> Wishes,****
>
> Manfred****
>
> ** **
>
> ** **
>
> ** **
>
> *Von:* Anthony Nadalin [mailto:[email-masked]]
> *Gesendet:* Freitag, 19. Juli 2013 18:12
> *An:* Prateek Mishra; Manfred Steyer
> *Cc:* [email-masked]
> *Betreff:* RE: [OAUTH-WG] SAML-like ActAs****
>
> ** **
>
> You can accomplish the ActAs semantics with Assertions profile, while a
> bit clumsy the basics are in place, the only issue is that you don’t have
> any way to indicate the formal semantics****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Prateek Mishra
> *Sent:* Friday, July 19, 2013 9:03 AM
> *To:* Manfred Steyer
> *Cc:* [email-masked]
> *Subject:* Re: [OAUTH-WG] SAML-like ActAs****
>
> ** **
>
> Hi Manfred,
>
> to offer genuine interoperability in this area.****
>
> https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ ****
>
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/   ****
>
> https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/****
>
>
> - prateek****
> ** **
> Hi,****
>  ****
> are there plans for supporting delegation-styles like ActAs or OnBehalfOf
> in SAML?****
>
>  ****
>
> thing, when one wants to use OAuth 2 within an enterprise-environment. ***
> *
>
>  ****
>
> I know, that OAuth 2 has been created for web-scenarios, but it’s a fact
> that OAuth 2 is used as a “REST-friedly” alternative to WS-* in the area of
> service-security. ****
>
>  ****
>
> scenario?****
>  ****
> Wishes,****
> Manfred****
> ** **
> _______________________________________________****
>
> OAuth mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
> ** **
>

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 19 Jul 2013 20:12:59 +0000

Right, and one of the main ways you'd use the chaining grant is by parsing the incoming token as an assertion of some type. They're all blocks that are made to fit together.

 -- Justin

On Jul 19, 2013, at 3:32 PM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:

FWIW, the 3 assertion documents are more targeted at cross domain type use cases. For example, assuming a trust (and liklely legal) relationship is in place, some corporate system acting as the client can trade a SAML token in at the AS of a SaaS provider for an OAuth access token, which can then be used to do things at the SaaS's RSs 'on behalf' of the subject identified in the assertion. That's not the only way it could be deployed but was one of the main motivating use cases.

General access tokens are undefined so one could structure them in a way that works with one of the assertion grants.

On Fri, Jul 19, 2013 at 10:40 AM, Manfred Steyer <[email-masked]<mailto:[email-masked]>> wrote:
Hi Nadalin,

that means, that I would use an existing OAuth-2-Token as the assertion for requesting another OAuth-2-Token, right?

Section 5.2.  „General Assertion Format and Processing Rules” of this draft says, that the assertion has to contain an Issuer as well as an audience. The OAuth-2-Token doesn’t have such fields by definition, but one can argue, that it is associated with an issuer (= auth-server) as well with a scope, which could be seen as the audience in this case.

Am I right?

Wishes,
Manfred

Von: Anthony Nadalin [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Gesendet: Freitag, 19. Juli 2013 18:12
An: Prateek Mishra; Manfred Steyer
Cc: [email-masked]<mailto:[email-masked]>
Betreff: RE: [OAUTH-WG] SAML-like ActAs

You can accomplish the ActAs semantics with Assertions profile, while a bit clumsy the basics are in place, the only issue is that you don’t have any way to indicate the formal semantics

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Prateek Mishra
Sent: Friday, July 19, 2013 9:03 AM
To: Manfred Steyer
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] SAML-like ActAs

Hi Manfred,

- prateek

Hi,

I know, that OAuth 2 has been created for web-scenarios, but it’s a fact that OAuth 2 is used as a “REST-friedly” alternative to WS-* in the area of service-security.

Wishes,
Manfred

OAuth mailing list