On 7/17/2014 11:00 AM, Stian Thorgersen wrote:
Just started on this. Quick summary of my attack plan:
1. Remove AccessToken from AccessCode. Instead add List<String> rolesRequested and
create AccessToken in TokenService.accessCodeToToken. Any reasons why this wouldn't
work?
2. Move some info from AccessCode to UserSession, and remove anything redundant. For
example username used to login, auth-method (social or form), remember-me.
3. Add info from AccessCode to UserSessionProvider and send signed key instead as the
code query param.
With regards to the required info here's what I've come up with:
To verify the code:
* Need to know it hasn't been done before - can either be done by having a timestamp
on ClientAssociation that is incremented every time a code is requested/used, or by having
a ClientAssociation per-code. As we'll need to store more specific to a code than just
the fact it has been used or not, I think it's best to just have a ClientAssociation
per-code
* Not expired - no prob
* Session active - no prob
* redirect_uri when retrieving code matches redirect_uri query param when swapping for
token - we don't do this currently I think, but spec requires it. This would require a
ClientAssociation per-code.
* Correct client_id - no prob, just make sure code belongs to the client_id query param
Create a ClientAssociation per AccessCode. As there is a refresh token
created per access code. What's great is that you have a log of refresh
token creation times too.
Then to create the token we need:
* List of roles requested - the union of user roles and app/client scope. This would
require a ClientAssociation per-code as the role-mappings/scope could change between user
granted the roles to the client and the code is exchanged. Also in the future once we add
a scope query param this will be required.
* Realm - no prob, user-session is associated with a realm
* Client - no prob, ClientAssociation is associated with a client
* User - no prob, user-session is associated with a user
* Session - no prob, user-session is a session ;)
All in all it seems like a bit more work than I initially considered. Or am I attacking
this completely wrong?!?
It is a lot of work, yes. Changes to a lot of files too.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com