Java security annotations ignored - java

I'm building a Maven Web Application user authentication. I created a new JDBC Realm in Glassfish and setup my domain classes with JPA. I can login with some created users and can check if they have a specific role. But when i secure a bean i always can access it.... The security annotation is ignored, for example #RolesAllowed, #DenyAll

Found the solution! Be sure your class is a EJB, for example with #Stateless. Then the authorization annotations will work!
http://www.oracle.com/technetwork/articles/javaee/security-annotation-142276.html

Related

REST authorization with exteral roles

I have a scenario where I have roles and permissions in a different system (where i need to make a REST call) and that system will specify whether I can access a particular resource or not.
I need to intercept my controller methods and that Interceptor should talk to external service and figure out the authorization. I am using just spring boot (no spring security).
It should be similar to this with JAX-RS but I'm looking in spring context. Can I achieve this using #RolesAllowed?
I would recommend using an interceptor:
http://docs.spring.io/spring/docs/current/spring-framework-reference/html/mvc.html#mvc-handlermapping
You need to have a configuration that you will annotate with (check spring documentation)
#EnableGlobalMethodSecurity(jsr250Enabled = true)
Then you will have to create your own access decision manager and register your own roles. With this you should be able to annotate your controllers to a specific user like #RolesAllowed("admin")

Spring Security Anonymous Authentication not initialised

I am using Spring4 with Spring Security 3.2.4.
I have some http configurations in my security configuration in order to host form based authentication and REST services (with authentication) together.
For the pages and REST services which require app-authentication everything works fine with my current configuration but for the pages which does not require authentication, such as login and register, the anonymous authentication is not initialised somehow. Speaking in Java:
SecurityContextHolder.getContext().getAuthentication() returns null.
I expect that anonymous authentication is initialised as the documentation (http://docs.spring.io/spring-security/site/docs/3.2.4.RELEASE/reference/htmlsingle/#introduction) refers:
Anonymous authentication support is provided automatically when using the HTTP configuration Spring Security 3.0 and can be customized (or disabled) using the element. You don’t need to configure the beans described here unless you are using traditional bean configuration.
Does anyone have an idea why does it not happen although the documentation refers? (Beside the fact, that the documentation for 3.2.4 refers to 3.0 version and some of the given configuration suggestions refer deprecated implementation)

Client not authorized for this invocation JAX-RS EJB error

I have been searching for a solution to this for a while, here goes...
I followed this tutorial to auto generate a jax-rs web service from a database: https://netbeans.org/kb/docs/websvc/rest.html
This works great, but when I try to secure the application by annotating the resource methods with #RolesAllowed("myRole"), I get this exception...
"WARNING: EJB5184:A system exception occurred during an invocation on EJB LicenceFacadeREST, method: public java.util.List resources.LicenceFacadeREST.findAll()
WARNING: javax.ejb.AccessLocalException: Client not authorized for this invocation"
I have narrowed it down to the EJB JACC policy check failing. When I do not use EJB/JPA in a resource class, the exception isn't thrown even when the #RolesAllowed annotation is present.
The full glassfish stack trace in fine print can be found here http://pastebin.com/AUPKWaqe
Here's some extra information, I followed the Jersey security guide below. https://jersey.java.net/documentation/latest/security.html#d0e10816
I used the ContainerRequestFilter to authenticate, here I'd set a custom implementation of SecurityContext if the authentication was successful which the rolesalloweddynamic feature would use along with the rolesallowed annotations to authorise access to a specific resource.
These three components allowed me to authenticate and authorise on an application level, not on a container level.
This worked great until my application was converted from a servlet to a EJB/servlet (I added a stateless ejb annotation to a jax-rs resource class). EJB uses the rolesallowed annotation to restrict access to its bean methods at a container level, therefore it conflicted with my application level authentication/authorisation.
I'm still searching for a comphrensive solution, even if it's disabling EJB level method security so I can leave it to the ContainerRequestFilter to authenticate and the rolesalloweddynamicfeature to authorise.

Role based security for OSGi

I am searching for a security framework that allows role based security for OSGi services as well as CXF webservices.
Some time ago I already used spring security but as we now switched to blueprint it is not an option anymore as far as I understood. To configure the access rules I would like to mainly use the standard #RolesAllowed annotation. So what are my best starting points? I also thought about implementing this myself as a blueprint extension but I would prefer an existing solution.
I would suggest you go with Apache Shiro instead, http://shiro.apache.org/ .
It provides easy API's for authentication, authorization, cryptography, and session management. It can also be easily deployed inside a OSGI container. Some pros of Apache Shiro are listed here Apache Shiro vs Java EE native APIs
In the mean time I created a blueprint extension for authorization based on JAAS and Java EE annoations (#RolesAllowed, #PermitAll, #DenyAll). You can add the extension to any blueprint file. It will then scan all beans for these annoations and intercept calls if they are found. It uses an existing JAAS context to get the roles of the user.
So prerequisite for this is doing a JAAS login. I have also created a CXF JAASAuthentication feature that logs in a user based on basic auth or ws security username principal. The module works together with the Apache Karaf JAAS support. So all karaf users and roles apply.
I will create a tutorial to show how to use all of this once the aries blueprint release that includes the authorization module is out. In the mean time I would be happy if you try it out and report any problems you have.
Btw. another approach for karaf is the role based access control for OSGi services that is built into karaf 3+. It does not work with annotations but is also easy to use. See
http://coderthoughts.blogspot.de/2013/10/role-based-access-control-for-karaf.html

Setting the Roles for #RolesAllowed in JAX-RS using jersey

I tried using Basic Authentication by changing the server.xml config of Tomcat 6.0 but it did not worked: BASIC authentication in jersey JAX-RS service and Tomcat 6.0 getting failed
Hence I am opting a way where no server specific config is needed and I can add up the roles directly in my code (either client or server; not sure about theavailable options).
Please provide me some ideas about the possible options for setting the user roles so that I can authenticate my Web Service methods using the #RolesAllowed annotation.
You need to go back and figure out why your security constraints weren't working. Maybe start with the default file realm before moving on to JDBC realms. #RolesAllowed in an annotation that triggers behavior in the container.
If you really want to do it yourself (a bad idea) they you'd probably start by creating a custom servlet filter that implemented the entire basic http challenge mechanism. Next you'd have to replace the SecurityContext provider in Jersey.
They "thing" that enables #RolesAllowed in jersey is this: http://java.net/projects/jersey/sources/svn/content/trunk/jersey/jersey-server/src/main/java/com/sun/jersey/api/container/filter/RolesAllowedResourceFilterFactory.java Which, by the way, don't forget to add as an init-param to your jersey servlet. The RolesAllowedResourceFilterFactory gets its security info from an injected SecurityContext which I'm sure at some point just delegates off to the Servlet API for credential info.
So basically if you don't want to take the time to get security constraints working you are going to end up replacing most of the chain...like I said, a bad idea.
The features on application servers are there to keep you from having to spend time creating infrastructure code, if you write your own infrastructure code you're going to have a bad time.

Categories

Resources