[
https://issues.apache.org/jira/browse/SHINDIG-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Clarke closed SHINDIG-1732.
--------------------------------
> Restrictive OAuth2Client (endpoint whitelisting)
> ------------------------------------------------
>
> Key: SHINDIG-1732
> URL: https://issues.apache.org/jira/browse/SHINDIG-1732
> Project: Shindig
> Issue Type: Improvement
> Components: Java
> Affects Versions: 2.5.0-beta1
> Reporter: Adam Clarke
> Fix For: 2.5.0
>
> Attachments: 1732_20120504.patch
>
>
> I have received comments asking for improvements in the OAuth2 Consumer to
> help administrators with token security.
> One of these comments I plan on submitting a patch for is to allow
> OAuth2Clients to be defined in a way that restricts where it will send OAuth2
> tokens.
> One area of concern is already addressed with the "allowModuleOverride"
> setting.
> 1) Adminstrator creates an OAuth2Client and binds Gadget X to it.
> 2) Gadget X changes it's <ModulePrefs> to a new authorization and/or token
> url endpoint
> 3) If allowModuleOverride==true the OAuth2 Consumer will honor the
> ModulePrefs and initiate the dance wherever Gadget X indicates.
> 4) Especially when using "client_credentials" this may be dangerous because
> the admin's client_id/client_secret have been sent to a potentially untrusted
> endpoint.
> 5) Today adminstrator can set allowModuleOverride=false on the OAuth2Client
> and be assured the dance will only be initiated on the URLs they've setup,
> ignoring the gadgets preferences.
> Setting allowModuleOverride is sufficient to protect the client_id and
> client_secret. However, Gadget X can still issue a makeRequest to any URL it
> wants and the OAuth2 Consumer will send the access_token.
> This change will allow the administrator to define the valid servers/domains
> for an OAuth2Client and prevent the Consumer from sending tokens anywhere
> outside of the specified locations. This was particularly important for
> clients using "client_credentials" or other flows where compromised
> access_tokens can open up large amounts of data on a server.
> Any suggestions on how to effectively implement the token whitelist are
> appreciated...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
