Hi Ivo, 2010/12/10 Ivo Ladage-van Doorn <Ivo.Ladage-vanDoorn at gxsoftware.com>: > Hi All, > > > > In 0.1.0 we are working on oAuth, allowing us to secure our API?s. One of > the API?s that needs to be secured is the REST API (the current user REST > API for example has no security at all). Though oAuth provides us > authentication, it does not provide authorization. In the REST interface you > will be able to validate oAuth tokens, retrieve a userId from it and oAuth > ensures that the oAuth information send has not been tempered with. We > however still need to provide some mechanism to determine the access to > grant to this particular user. > > > > The JAX-RS spec supports only Basic and Digest authorization and we > (probably) cannot use (abuse) the javax security annotations for oAuth > authorization, since the JAX-RS implementation will react upon. There are > several scenario?s to secure the REST APIs: > > > > ????????? Scenario 1. Let it completely up to the implementation. So each > REST method should: > > o?? Validate oAuth token and throw a 401 if it is invalid > > o?? Invoke UserAdmin.getAuthorization(user).hasRole(role) to verify if the > role is implied by the users authorization context and throw a 401 if this > is not the case
-1 as it is complex, has tight coupling to auth provider and in general is unmanageable. > ????????? Scenario 2. Implement a REST call hook that intercepts all REST > calls and verifies authorization against a manageable list of access grants. > A gadget would be available where Roles can be assigned to each REST API (on > method level). Access is only true or false. > +1 for (at least) the first part. I think we will need the ability to intercept anything that comes into the container for management, monitoring, security concerns in general anyway. I also think access grants should be role based and manageable (or at least configurable). Btw I think access is per definition always true or false... I think I do not get your point? > ????????? Scenario 3. Using declarative security using annotations, in line > with the JAX-RS spec. Where JAX-RS uses javax security annotations (for > example @RolesAllowed and @PermitAll), we could add our own annotations > which will be quite similar but map onto UserAdmin instead of roles defined > in a web.xml. Yes we could use annotations, but I would like top stay with the spec and not invent our own propriatary annotations just yet. Problem might be how to manage this when developers put their roles in code. Either we need a "fixed" documented security model for roles that all need to conform to and will never provide a good fit for all cases. Alternatively we would need a mapping/convention for translationg between declared roles and confiigured roles without collisions. > ????????? Scenario 4. A mix off the scenario?s 2 and 3 is also possible. For > example using annotations like (our own) @DeclareRoles which could be > associated with actual roles in a manageable list. Advantage is that role > grants are not declarative anymore; they can be changed at runtime. It > allows a mix of using methods that do not need to be secured (like the > @PermitAll annotation in JAX-RS). +1 for manageable +0 for annotations -1 for own annotations > > What scenario do you think is the best one? Note that scenario 1 is always > possible, no matter what scenario we choose and always allows developers to > implement more fine-grained authorization checks. Are there more/better > alternatives? Not fully convinces about any of them (yet). I think Amdatu should be in control and I also think we should about security at the web container level. Why not deal with it there? Eg. What if the developer can declare a model using (standard) annotations and Amdatu is able to configure a role mapping at the web container level. I think this is more or less the way all containers do it and I think catching things at the web container level is good as it provides a generic approach for all web-resources. So somethiung allong the lines of.. GET /test HTTP/1.1 1) web container sets up security realm 2) web container identifies principal 3) web container checks configured security constraints 4) rest container checks declared allowed roles against principal (optional) 5) rest container invokes service (or not) Regards, Bram
