Subject: [OAUTH-WG] User and Client identity in the Assertion Flow

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 13 May 2010 12:38:12 +0200

In my perception, we reached consensus in the thread "Autonomous clients 
and resource owners (editorial)" that the assertion flow should support 
clients acting on behalf of users, not only autonomous clients.

The specification currently states "This flow is suitable when the 
client is acting autonomously or on behalf of the end-user (based on the 
content of the assertion used).", which is fine with me.

Im struggling to understand how the flow handles the two required 
identities, the client and the end-user. I basically see two options:

1) the assertion attests both identities. I'm not aware of any identity 
framework attesting two identities in a single assertion.

2) If we assume the assertion attests the end-user's identity only, 
there is the need for additional parameters used to authenticate the 
client. From my point of view, the situation is similar to the "Username 
and Password Flow". There, the specification defines two credential sets 
(username/password and client_id/client_secret) two prove both identities.

Therefore, I would propose to add optional client_id/client_secret 
parameters (or an Authorization header) to pass the client credentials 
to the assertion flow if the assertion contains the end-user identity. 
Alternatively, one could add another flow to the spec, probably called 
"User Assertion Flow".

Any thoughts?

regards,
Torsten.

---

From: Paul Madsen <[email-masked]>
Date: Thu, 13 May 2010 07:05:30 -0400

Torsten, have you thought about the relevance of the <saml:Issuer> for 
identifying the client?

Identify if not authenticate.

On 5/13/2010 6:38 AM, Torsten Lodderstedt wrote:
> In my perception, we reached consensus in the thread "Autonomous 
> clients and resource owners (editorial)" that the assertion flow 
> should support clients acting on behalf of users, not only autonomous 
> clients.
>
> client is acting autonomously or on behalf of the end-user (based on 
> the content of the assertion used).", which is fine with me.
>
> 1) the assertion attests both identities. I'm not aware of any 
> identity framework attesting two identities in a single assertion.
>
> client. From my point of view, the situation is similar to the 
> "Username and Password Flow". There, the specification defines two 
> credential sets (username/password and client_id/client_secret) two 
> prove both identities.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 13 May 2010 13:26:00 +0200

> Identify if not authenticate.

Thanks for your advice.

I would not expect the issuer to by the client in that game. In my 
opinion a client could be a website, which obtains an assertion from an 
authorization server, let's assume a SAML assertion, during login. So 
the authorization server would be the issuer of the SAML assertion. In 
the next step, the client wants to exchange that assertion for an access 
token needed to access services on behalf of the client.

I would expect the OAuth authorization server to validate the following 
aspects:
- What is the issuer of the assertion and do I accept assertions from 
that particular issuer?
- Is that particular client allowed to swap such assertions?
- Do I know the end-user identified by the SAML assertions Subject?

regards,
Torsten.

>> parameters (or an Authorization header) to pass the client 
>> credentials to the assertion flow if the assertion contains the 
>> end-user identity. Alternatively, one could add another flow to the 
>> spec, probably called "User Assertion Flow".
>>
>> Any thoughts?
>>
>> regards,
>> Torsten.
>>

---

From: Chuck Mortimore <[email-masked]>
Date: Thu, 13 May 2010 08:26:20 -0700

Our plan is to treat SAML assertions passed over the assertion flow as bearer assertions, so I believe we have everything we need contained within the assertion (issuer + audience + signature).  That being said, if we want this to be an extensible flow, not all assertion formats will be so transparent.

I think this is a reasonable suggestion, as long as the clientid/secret are entirely optional.    Not in support of a second User Assertion Flow.

-cmort

On 5/13/10 3:38 AM, "Torsten Lodderstedt" <[email-masked]> wrote:

Any thoughts?

regards,
Torsten.

---

From: Brian Eaton <[email-masked]>
Date: Thu, 13 May 2010 08:50:22 -0700

On Thu, May 13, 2010 at 8:26 AM, Chuck Mortimore
<[email-masked]> wrote:
> Our plan is to treat SAML assertions passed over the assertion flow as
> bearer assertions, so I believe we have everything we need contained within
> the assertion (issuer + audience + signature).  That being said, if we want
> this to be an extensible flow, not all assertion formats will be so
> transparent.
>
> I think this is a reasonable suggestion, as long as the clientid/secret are
> entirely optional.    Not in support of a second User Assertion Flow.

Yes.  This sounds right to me.

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 13 May 2010 09:02:09 -0700

Will be added to -05.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian Eaton
> Sent: Thursday, May 13, 2010 8:50 AM
> To: Chuck Mortimore
> Cc: [email-masked]
> Subject: Re: [OAUTH-WG] User and Client identity in the Assertion Flow
> 
> > bearer assertions, so I believe we have everything we need contained
> > within the assertion (issuer + audience + signature).  That being
> > said, if we want this to be an extensible flow, not all assertion
> > formats will be so transparent.
> >
> > I think this is a reasonable suggestion, as long as the
> > clientid/secret are entirely optional.    Not in support of a second User
> Assertion Flow.
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 13 May 2010 18:11:43 +0200

Thanks.

---

From: Prateek Mishra <[email-masked]>
Date: Thu, 13 May 2010 13:15:04 -0400

SAML 2.0 assertions can represent a variety (very large) of 
relationships between the presenter, issuer, subject, means of 
confirmation and so on and so forth.
So representing multiple identities - i am server foo but I am acting 
for joe - is not very difficult.

We can profile these versus adding parameters to the flows.

- prateek

> clientid/secret are entirely optional.    Not in support of a second 
> User Assertion Flow.
>
> -cmort
>
>
>     clients
>     identity
>     "Username
> ------------------------------------------------------------------------
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 13 May 2010 10:17:08 -0700

The flow is not SAML-specific.

EHL

> Of Prateek Mishra
> Sent: Thursday, May 13, 2010 10:15 AM
> To: [email-masked]
> SAML 2.0 assertions can represent a variety (very large) of relationships
> between the presenter, issuer, subject, means of confirmation and so on
> and so forth.
> So representing multiple identities - i am server foo but I am acting for joe - is
> not very difficult.
>