Case insensitive check for role in HttpServletRequest - java

The javax.servlet.http.HttpServletRequest class has a method called isUserInRole. I use this to check if a user has, for example, the admin role. However, that method is case sensitive. So, if the role in the request was Admin or ADMIN, then isUserInRole("admin") would be false. I use the isUserInRole method in a number of places accross multiple applications to check for a number of different roles.
Is there a way to achieve the isUserInRole functionality case-insensitively that does not require checking each different possible case combination with isUserInRole?

You could implement a filter that wraps requests using a HttpServletRequestWrapper - implement your HttpServletRequestWrapper to override the isUserInRole() method to make it case-insensitive (eg, configure all roles in upper-case, test role params by converting to upper-case).
A quick search will find plenty of HTTPServletRequestWrapper examples...

http://docs.oracle.com/javaee/6/tutorial/doc/gjiie.html
Just map multiple role names to the admin role:
<servlet>
<security-role-ref>
<role-name>admin</role-name>
<role-link>admin</role-link>
</security-role-ref>
<security-role-ref>
<role-name>Admin</role-name>
<role-link>admin</role-link>
</security-role-ref>
</servlet>
<security-role>
<role-name>admin</role-name>
</security-role>

Related

What is the authenticated uesr's role - Java

Good morning
I am using ejb2 (older application) on weblogic 10.
There are methods in my session beans that are secured to be executed by certain role.
Each of my ejb interface method I annotate with
`#ejb.permission role-name="role1, role2"`
Since some methods maybe executed by users in few different roles, how can I tell which role runs the method?
I know how to know if a "caller is in a certain role"
Principal principal = ctx.getCallerPrincipal() ;
boolean isRole = ctx.isCallerInRole("role2") ;
But, is there a way to obtain the actual caller's role? Something like "getCallerRole()" or such?
In the xml file "ejb-security-roles.xml" I specify what roles are in application domain
<security-role>
<role-name>role1</role-name>
<role-name>role2</role-name>
</security-role>
Then, each of those roles are mapped to LDAP in the "weblogic-security-role-assignment.xml"
<security-role-assignment>
<role-name>role1</role-name>
<principal-name>Role1User</principal-name>
</security-role-assignment>
<security-role-assignment>
<role-name>role2</role-name>
<principal-name>Role2User</principal-name>
</security-role-assignment>`
Can anyone help, directing me to the right path of thinking?
Just use if (ctx.isCallerInRole("role2")) {
According to Oracle Accessing an Enterprise Bean Caller’s Security Context,
it is only way to check user's role.

How does a servlets filter identify next destination is another filter or a servlet/jsp?

We usually end up with writing <url-pattern>/*</url-pattern> in web.xml for any Filter in servlets.
<filter-mapping>
<filter-name>requestRedirectorFilter</filter-name>
<url-pattern>/action</url-pattern>
</filter-mapping>`.
Now my doubt is how java identifies which is next servlet/jsp is? Because any request we make through
request.getRequestDispatcher("/ABCXYZ").forward(request, (HttpServletResponse)servletResponse);
to navigate on next servlet/jsp, container by default is going to search in web.xml. And in web.xml <url-pattern>/*</url-pattern> is already there for the filter we use. Exactly here actual problem begins.
If <url-pattern>/*</url-pattern> [which is acting like a universal receiver for any request] is already there in web.xml then How the heck container knows to follow <url-pattern>/ABCXYZ</url-pattern> instead <url-pattern>/*</url-pattern> ? Please share your views and knowledge on this front.
Servlet Matching Procedure
A request may match more than one servlet-mapping in a given context. The servlet container uses a straightforward matching procedure to determine the best match.
The matching procedure has four simple rules.
First, the container prefers an exact path match over a wildcard path match.
Second, the container prefers to match the longest pattern.
Third, the container prefers path matches over filetype matches.
Finally, the pattern <url-pattern>/</url-pattern> always matches any request that no other pattern matches.
For example, a context web.xml file can map the home page for an online catalog to one pattern and the search page for the catalog to a different pattern, as shown below:
<servlet-mapping>
<servlet-name>catalogBrowse</servlet-name>
<url-pattern>/Catalog/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>catalogSearch</servlet-name>
<url-pattern>/Catalog/search/*</url-pattern>
</servlet-mapping>
Below figure illustrates the matching process for a context. Since the container prefers to match the longest pattern, a URL that includes /Catalog/search/ always matches the mapping for catalogSearch rather than the mapping for catalogBrowse.
URL pattern matching
It is copied form the below link if your are not interested to go to the link.
Please have a look at URL Patterns where it is described in detail with examples.

Security constraint in web.xml for authenticated users without role memberships

I am quite desperate, because I think there must be an easy solution to my problem but I am searching - to no avail.
I am using a custom Realm in Glassfish 3.1.1. This custom realm (implements AppservPasswordLoginModuleInterface) takes a security token from the HTTPS request, validates the security token and then returns the user to Glassfish.
The problem is that the security token does not contain any groups, meaning that the method public String[] getGroupsList() or the custom realm returns an empty list (correctly, because there are no roles in the security token).
That said, I would like to have a security contraint that only validated users can login. I know that I can use the following constraint in web.xml:
<security-constraint>
<web-resource-collection>
<web-resource-name>mywebapp</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>Users</role-name>
</auth-constraint>
</security-constraint>
But because I don't have any groups, I cannot map any groups to roles, and therefore I cannot use the auth-constraint with role-name.
Is there a way in web.xml to define that only authenticated users are allowed, ignoring in which role they are and ignoring whether they are in any role at all.
There are a couple of solutions which I cannot implement:
I cannot change the underlying LDAP to include roles, because the LDAP schema and the way how LDAP users are mapped to security tokens our out of scope.
I have to use the current custom realm handler, I cannot replace it with one of my own which just returns a default group. I did try this once, and it worked. But I cannot replace the existing custom realm with my own because the custom realm should be generic.
But I really think there should be a way in web.xml just to say: Ignore all groups and roles, I just want an authenticated user?
Any help would be appreciated.
Pretty old, but for those looking for an answer, you can use an * role name:
<auth-constraint>
<role-name>*</role-name>
</auth-constraint>
This guy managed to solve it.
Use two asterisks:
<auth-constraint>
<role-name>**</role-name>
</auth-constraint>
See section 13.8 of the Servlet 4.0 spec: https://javaee.github.io/servlet-spec/downloads/servlet-4.0/servlet-4_0_FINAL.pdf
The single asterisk means a user must have at least one of any declared role vs double asterisks means a user simply must be authenticated. So with single asterisk a user must have one of the roles declared in the security-role section of the web.xml, and it appears some application servers (like JBoss/Wildfly) allow you to also put a single asterisk in this section to make this work similarly to the double asterisks. This single asterisk in the security-role section appears to be non-standard and likely non-portable:
<security-role>
<role-name>*</role-name>
</security-role>

Servlet Filter - Dont apply filter to a specific one

I have a web-application with login screen backed up by an Authentication Filter.
I have the following in my web.xml
<filter>
<filter-name>AuthenticationFilter</filter-name>
<display-name>AuthenticationFilter</display-name>
<filter-class>com.mycompany.secutity.AuthenticationFilter</filter-class>
</filter>
And I have the following mapping -
<filter-mapping>
<filter-name>AuthenticationFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
But now I want to add an exception where for a specific servlet /web/MyNewServlet, I want to bypass the authenctication filter. How can we do this?
There are two ways in which you could do this:
Remap the /* pattern to another pattern like /subdir/*, and thereby avoid the AuthenticationFilter from being applied against /web/MyNewServlet. This is a cumbersome process as you might have several URLs in your web-application that now need to be remapped. I would suggest doing this early in your development, or when you do not have too many URLs to remap.
Include an exclusion rule programatically inside your Filter implementation. You will need to use HttpServletRequest.getServletPath and similar methods to verify if the URL fragment contains /web/MyNewServlet, and then chain the filter to the next filter or the servlet, instead of executing the body of the filter.
Extending Vineet's idea slightly, you could add another filter, called something like DoesNotNeedAuthenticationFilter, which runs before the AuthenticationFilter, and just sets an attribute DOES_NOT_NEED_AUTHENTICATION on the request. The AuthenticationFilter can then check for that attribute, and pass any requests which have it. You can then use the normal filter mapping mechanism to apply the DoesNotNeedAuthenticationFilter to the appropriate URLs or servlets.

url-pattern and wildcards

While configuring the security constraints for a web-module's roles in J2EE application I'm having the following problem:
Application:
Giving a servlet named customersServlet, which receives two parameters in the URL:
A string representing an operation (INS, UPD, DLT and DSP).
An identification number to identify a customer on which the operation will be performed.
E.G.: the url /servlet/cusotmersServlet?UPD,5 is used to update customer number 5 data, and the url /servlet/customersServlet?DLT,8 is used to delete customer number 8.
Problem:
If I use this security-constraint the servlet can only be accessed by the role specified, which is ok:
<security-constraint>
<web-resource-collection>
<web-resource-name>...</web-resource-name>
<url-pattern>/servlet/clientsServlet*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>clientAdmin</role-name>
</auth-constraint>
</security-constraint>
But I want to restrict the ability to insert customers only to a role named clientAdmin.
I've tried several url patterns but none of them works as I want (all of them allow every role to access the servlet with any parameter):
<url-pattern>/servlet/clientsServlet?INS,*</url-pattern>
<url-pattern>/servlet/clientsServlet?INS/*</url-pattern>
...
How to use the wildcard * in the url-pattern tag?
Note: The application cannot be changed, so I need a solution that only implies touching the deployment descriptor.
The <url-pattern> tag only allows a very restricted subset of wildcards. This is probably not what you are used to from other situations, where a * can be used at any position. You can download the Servlet specification here:
http://jcp.org/aboutJava/communityprocess/mrel/jsr154/index2.html
Section SRV.11.2 of that document describes how these URL patterns are interpreted. In particular, the * does not mean "zero or more arbitrary characters" here.
Note: The application cannot be changed, so I need a solution that only implies touching the deployment descriptor.
Not sure if this counts as an application change - perhaps you could think of it as a plug-in. You could add a Filter. This would require the ability to add a new JAR to WEB-INF/libs and the ability to define the filter in web.xml. The Filter would allow you to restrict access programmatically.

Categories

Resources