[ 
http://jira.amdatu.org/jira/browse/AMDATU-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivo Ladage - van Doorn reassigned AMDATU-246:
---------------------------------------------

    Assignee: Bram de Kruijff  (was: Ivo Ladage - van Doorn)

> Centralize login context information
> ------------------------------------
>
>                 Key: AMDATU-246
>                 URL: http://jira.amdatu.org/jira/browse/AMDATU-246
>             Project: Amdatu
>          Issue Type: Task
>          Components: Amdatu Auth
>    Affects Versions: 0.1.0
>            Reporter: Ivo Ladage - van Doorn
>            Assignee: Bram de Kruijff
>             Fix For: 0.1.0
>
>
> In many parts of the software you need to know what user is currently logged 
> in. Most of the times for authorization checks, in other cases to return 
> user-dependent information. Examples of such components are:
> - Login REST service
> - oAuth authorize token servlet
> - UserAdmin REST service
> Note that for OpenSocial gadgets, this information is available in the 
> SecurityToken send along with each request. That is fine for gadgets, but we 
> need a similar mechanism for non-OpenSocial components. For that reason the 
> username was added to the amdatu_token, which is send along with each 
> request. This is the way it is currently implemented in the components above.
> However, this approach is not ideal for the following reasons:
> - Each service will need to retrieve the token from the request, check if the 
> token is valid and decrypt the username from the token. This means that 
> during the lifetime of a request, the same token may be validated and 
> decrypted many times, while doing this only once should have been sufficient.
> - It depends on the HTTP request being available. An example of where this is 
> problematic is CourseService.getAvailableCourses(Person). This service should 
> in fact validate that the user that requests this information is a 'Teacher'. 
> With the current implementation this is not possible, other then passing the 
> HTTP request.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to