[mitreid-connect] Bulk data access security under OIDC

Tony Fendall [DATACOM] TonyF at datacom.co.nz
Tue Sep 29 00:10:54 EDT 2015


Hi

I have created a REST service on my server which I want specific clients to be able to access.  To support this I have:

*         Setup my sample client to request an access token using the client credentials grant type

*         Protected my REST service using @PreAuthorize("hasRole('ROLE_CLIENT')")

The problem I have found is that when using the access token on a request to my service, the security context on the server does not hold ROLE_CLIENT as I would expect it to.  Instead it has no authorities at all.

Can someone please explain how I should be implementing this?  Perhaps I should be protecting my service with a specific scope rather than filtering on an authority, but I would prefer to use both if possible.


What I have found so far is:

If I make the client credentials grant type request as I would expect to, then:

*         During the initial request to /token?grant_type=client_credentials, the security context does contain ROLE_CLIENT which is given by DefaultClientUserDetailsService

*         However this role is not saved against the authentication holder for the access token

If I update the client_authority table database directly, and assign ROLE_CLIENT to the client I am using, then:

*         The role is picked up by the token endpoint and saved against the access token.  Calls to my REST service work as expected

*         However the role is also saved in the DB against all user access tokens.  It doesn't give the users ROLE_CLIENT when using the access token due to user authorities being used ahead of client authorities in OAuth2Authentication, but it still feels like I might be doing something wrong here?

I can also make requests to my REST service directly by passing client_id and client_secret as query strings and using the ClientCredentialsTokenEndpointFilter:

*         This puts ROLE_CLIENT in the security context as I would expect and lets my service work

*         However I would prefer to use an access token for this request if possible rather than passing the client secret across with every request

Thanks for your help!
Tony


From: Justin Richer [mailto:jricher at mit.edu]
Sent: Friday, 7 August 2015 1:11 a.m.
To: Tony Fendall [DATACOM]; mitreid-connect at mit.edu
Subject: Re: [mitreid-connect] Bulk data access security under OIDC

The client credentials grant type was created specifically for this use case: a client acting on its own behalf. As such, I'd go with option 2. You can lock the server down such that it can only give this special scope to this one client and no other clients or users can access it.

 -- Justin
On 8/5/2015 11:40 PM, Tony Fendall [DATACOM] wrote:
Hello

I have an existing web application which uses MITREid Connect and exposes a REST API.  Currently passing access tokens to the REST API gives access only to the data of the current user (who own the access token).  I want to extend this system and give a specific client access to data of all users, and am wondering how best to implement this.

Option 1:
Create a specific user account with ROLE_BULK_ACCESS, then generate an access token as this user.  When holding this specific access token the client application can then inherit this bulk access role giving them access to the new end points.

Option 2:
Use client credentials (client id and secret) to generate a client access token.  Give this client a specific "bulk access" scope which can then be used to control access to the new end points.


Do either of those options sound like a reasonable solution?  Any advice would be gratefully received.

Thanks
Tony Fendall




_______________________________________________

mitreid-connect mailing list

mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>

http://mailman.mit.edu/mailman/listinfo/mitreid-connect

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20150929/da431c66/attachment.html


More information about the mitreid-connect mailing list