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.
Related
I am using Shiro Security to secure a JSF project.
It is working as expected, including calls to a remote EJB (that is unsecured). However, when a call to the unsecure EJB is made, i have the following warn, but the method is executed without a problem:
IIOP1002: Principal propagation: Cannot find principal information in subject
What does this exactly mean? What should I do to fix this? I need to execute the method in a remote EJB from a secured application and this warning is getting dumped to the log everytime a call to the EJB is made (this occurs multiple times).
Edit:
The warn doesn't occur when I deploy the project in the same Glassfish server as the EJB.
Edit 2:
I thought about inserting the principal information in the InitialContext, before doing the call to the EJB, like this:
Hashtable env = new Hashtable();
env.put(Context.SECURITY_PRINCIPAL, SecurityUtils.getSubject().getPrincipal());
ctx = new InitialContext(env);
Still no luck.
SecurityUtils is from org.apache.shiro.SecurityUtils library.
Apache Shiro is an application layer security solution. As far as I can tell it is not integrated with your application server in any way.
A Java EE server normally expects to be in charge of authentication, authorisation, etc. Consequently it is then in a position to be able to propagate credentials correctly when making both local and remote EJB calls. This is how features like javax.annotation.security.RolesAllowed are implemented.
Shiro propagates its principal to javax.security.Principal, which remote EJBs don't understand. The Java principal has to be nulled out.
This is done in Shiro EE integration module which will be integrated into Shiro with version 2.0+
I am trying to secure my Webapplication which is based on a Spring MVC project containing REST controllers and Angular JS pages that get all their data from these controllers.
I am not at all familiar with Spring boot, just with 'classic spring'. I'd like to use the token based authentication which JHipster creates a skeleton for.
What needs to be done to get that security part and migrate it to my current Spring project? I tried copying relevant classes and the Token generation and such works, but the SecurityConfiguration seems to do nothing (no URL's are authenticated while I do say they need to be in the config, the tokenfilter never gets called etc.)
There's possibly some structural/ configurational differences between Spring and Spring boot which cause this?
What needs to be done to get the security mechanism working in a regular Spring application?
What is working:
- token generation
What is not working:
- every REST call goes through no matter if it's behind an .authenticated() URL
- the token filter never checks if there's a token and thus doesn't validate the token
Everything token-wise is okay, everything url-security wise is not at all okay.
(I've been trying to solve this for 3 days now and I just don't see where I'm going wrong.)
All help/ insights/ tips much appreciated as always.
I am attempting to set the X-Frame-Options to DENY for all management endpoints, particularly the /error endpoint. I have the following in my application.properties of my Spring Boot application.
security.headers.frame=true
management.security.enabled=true
management.port=8001
When I go to http://localhost:8001/error I do not have the X-Frame-Options header, however the http://localhost:8001/trace endpoint does have the header. How do I configure my application.properties or what do I need to override to get that response header for the error endpoint?
Going through the current Spring Boot source (1.1.7.RELEASE), I don't see anyway that you can do what you want without totally doing away with the Security auto-configuration.
That is because in order for an endpoint to be eligible for the customized HTTP Headers (like X-Frame-Options) it needs to be a bean in the parent context (the one that is associated with the application on the normal port) that implements MvcEndpoint. Such beans are HealthMvcEndpoint, JolokiaMvcEndpoint etc.
My statement adove can be viewed in code at ManagementSecurityAutoConfiguration in the ManagementWebSecurityConfigurerAdapter.configure method (endpointHandlerMapping is created from the MvcEndpoint implementation beans).
The error page for the management app, is ManagementErrorEndpoint that is created in errorEndpoint of EndpointWebMvcChildContextConfiguration which is triggered when the child context is created (due the inclusion of the management app), which is too late to be included in the endpoints that supported for HTTP Headers customization
The /error endpoint is not an Actuator Endpoint and it's not secured by default (lots of errors can happen when a user is not authenticated). You could maybe make it available to anonymous users, but my guess is not even that would prevent some nasty infinite loops, where there is a mistake in the security configuration. I'm sure there's another way to add the header without Spring Security?
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)
I need to interface an existing application with Acegi/Spring security.
In order to get started I am looking for one simple piece of information: in this context, will HttpServletRequest.getUserPrincipal() called from my application properly return the username obtained through Spring (as opposed to using Spring-specific objects)? I have Googled conflicting information on this.
I assume that if Acegi is implemented with filters, it is able to overload the Servlet API's getUserPrincipal(), right?
Subsidiary question: if this is not the case by default, is there any way to turn it on?
Thanks,
-Erik
As previous user has answer, spring security support the getUserPrincipal and isUserInRole. Here is how spring security does it.
When you configure spring, it can load the following filters:
http://static.springframework.org/spring-security/site/reference/html/ns-config.html#filter-stack
As part of the standard filter configuration the SecurityContextHolderAwareRequestFilter filter is loaded.
Examining the filter # https://fisheye.springsource.org/browse/spring-security/tags/spring-security-parent-2.0.4/core/src/main/java/org/springframework/security/wrapper/SecurityContextHolderAwareRequestFilter.java?r=2514
You can see it wraps and changes the HttpServletRequest object to the SecurityContextHolderAwareRequestWrapper class which extends HttpServletRequestWrapper which implements HttpServletRequest and feed it back to the standard Servlet Filter doFilter chain. Since spring security filter should be configured as the first filter, all subsequent classes will see the SecurityContextHolderAwareRequestWrapper instead. This includes JSP pages or Servlets behind this filter.
When you make a call to isUserInRole or getUserPrincipal from the JSP page, Servlet or any framework behind this filter, it is calling the HttpServletRequest implementation from Spring Security.
If you use the security filter, yes it does. I believe this is the default behavior.
Exactly which class you're getting back depends on your configuration, but they all implement the Principal interface by way of Spring's own org.springframework.security.Authentication interface which extends it.
I've used request.getUserPrincipal() and request.isUserInRole() in a Spring application and it works seamlessly, even within JSPs.
I do believe that Spring Security stores this information in the SecurityContext and not in the request though. You could easily write a FilterSecurityInterceptor that can be configured to add this info to the request also.