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 * 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. * 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. * 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). 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? See also issue http://jira.amdatu.org/jira/browse/AMDATU-81 Regards, Ivo GX | Ivo Ladage-van Doorn | Product Architect | Wijchenseweg 111 | 6538 SW Nijmegen | The Netherlands | T +31(0)24 - 388 82 61 | F +31(0)24 - 388 86 21 | ivo.ladage-vandoorn at gxsoftware.com<mailto:ivo.ladage-vandoorn at gxsoftware.com> | www.gxsoftware.com<http://www.gxsoftware.com> | twitter.com/GXSoftware<http://twitter.com/GXSoftware> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.amdatu.org/pipermail/amdatu-developers/attachments/20101210/3ae7d5a5/attachment-0001.html
