Definitely, we have many common ideas!
I think we need to get an I-D out with a crisp proposal.
Igor
Kristoffer Gronowski wrote:
Hi Igor!
That is exactly what I would like to explore!
My thinking was that the authorization server should be quite simple.
There should be no advanced things like a policy server inside it.
As long as the authorization (AS) and the resource servers (RS) use the same
identity source (or trusted federation of it).
I was thinking of a simple interface that can work in layers.
1) The RS can ask the AS is this a valid token yes/no
2) Is this a valid token containing the following scopes?
3) Was this a token issued by a particular user X. (Based on sharing or
trusting in the identity source)
Or a combination of the above. In this way you can at least do a good
separation of concerns.
Except of the answer if the criteria was met I have been experimenting also in
returning metadata from the AS so that a RS interceptor can be built.
You would get all data about token lifetime, scopes attached and owner
information.
This would be a combination with the request input parameters. So you can start
off with making sure that #1 is valid.
Since the token needs to have been generated by the AS.
Then if you have a more dynamic policy that is very endpoint specific it is far
easier to implement it in code then in a general purpose policy server.
Then you can easily implement things like this protected resource needs scope X
or Y Mon-Fri while Z on weekends.
Another advantage is that the same code can work on your behalf in discovery
mode to actually give you a clue what is needed at this very moment to access.
The AS is just following strict rules and giving facts to you as a RS.
It is a pretty clean design but I am sure that it will not fit everyone's needs.
And I am not saying that policy server would go away but for simple REST
services this is a powerful framework where you do not have to mash all of you
implementation into one big thing.
So that it why I was thinking that it might be a candidate for an optional
interface that might be good to have.
With it people can develop Oauth protected services quicker since there is more
ready code to start from.
Does this still fit your vision too described this way?
BR Kristoffer
-----Original Message-----
From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com]
Sent: Monday, February 07, 2011 5:21 PM
To: Kristoffer Gronowski
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New Working Group Items?
Kristoffer,
I assume you mean an interface between the authorization server and the
resource server. If so, I believe it definitely merits a serious discussion,
and I support the idea in principle.
On this subject, I think we need even more work defining the token and linking it to the resource owner. Today's discussion between Eran and Phil once again made me think of insufficiency of the "opaque tokens."
Indeed, anything that comes with the OAuth flow is an OAuth token. (From the security point of view, of course, that also means that anything that can be INSERTED into an OAuth flow will be an OAuth token...) I am not criticizing the design decisions--I have agreed with all of them.
But going forward, I would like the resource owner, the end user (both human
and virtual) to 1) issue tokens or 2) outsource this work it it wishes. In the
latter case, the resource owner must at least understand what the token has
rather than just pass the token.
Ideally, I would like this to be an OAuth work item: OAuth WG works very well,
and it has gathered the best people to judge the task. I understand though that
token specification is not presently in the charter, and therefore it can be
discussed only in the context of changing the charter. And so I first wrote
this in response to the item that you proposed, which I think is one step
toward what I thought should be done.
Igor
Kristoffer Gronowski wrote:
...
IMO there is one item missing and that is to create an optional formal
interface between the authorization server and the protected resource.
It could increase the productivity of creating the oauth protected web
services when the auth server can be treated as an off the shelf piece
of code.
Then it would be up to the auth server to also provide an number of
other extension like the discovery, token revocation and other.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
