Am 13.05.2010 13:05, schrieb Paul Madsen:
Torsten, have you thought about the relevance of the <saml:Issuer> for
identifying the client?
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.
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.
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.
_______________________________________________
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
