I'm trying to create a login page which authenticates the users via a JDBCRealm on my Glassfish server (i think this is the easiest way), so far i managed to get it working.
But in the User table in the DB i have a "is_active" column, when this column contains "false", i would like the server to reject the login attempt (just like with a wrong password).
I'm fairly new to java ee and have no idea where i should be looking for this. Does anyone know how to do so?
First of all I have no earthly reason why glassfish does not provide a better default security realm. JDBCRealm does not support salted user passwords, and also does not support the more modern hashing techniques such as PBKDF2 etc...
That being said, I think if you want to use the default JDBCRealm, here is a way to make it enforce access to certain pages for only "active" users.
Have three tables similar to the ones below (these are for postgres).
CREATE TABLE users
(
user_id serial PRIMARY KEY,
email character varying(255) NOT NULL UNIQUE,
passhash character varying(255) NOT NULL
);
CREATE TABLE users_groups
(
users_groups_id serial PRIMARY KEY,
user_email character varying(255) NOT NULL REFERENCES users(email),
group_name character varying(20) NOT NULL REFERENCES groups(group_name)
);
CREATE TABLE groups
(
group_name character varying(20) PRIMARY KEY
);
Instead of an is_active column on the users table, make an "active" group. Then you can enforce access to portions of your web app to members of that group/role (make sure to set up the mapping between groups and roles properly).
For example, if you wanted all urls to only be accessible by "active" users, you could put something like the below in your web.xml:
<security-constraint>
<web-resource-collection>
<web-resource-name>private</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>active</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
I assume you got your password hashing code working properly, and the db tables set up successfully with glassfish? It is arguably a pain in the neck.
Documentation on working with roles/groups:
http://docs.oracle.com/javaee/6/tutorial/doc/bnbxj.html
Related
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.
I have the mechanism to save cookies at the client-side. But when I was trying to implement remember-me using spring security I came upon this tutorial :
http://static.springsource.org/spring-security/site/docs/3.0.x/reference/remember-me.html#remember-me-persistent-token
but here everything is abstract and no examples are given..
Can someone tell me how can I use the interfaces mentioned in this tutorial in my application where I need to implement persistent cookies... And kindly tell me what do I need to define in my security.xml file?
I am authenticating my user against RESTful services..
The official documentation is not abstract. Turning on remember-me with Spring Security is very simple (I suppose that Spring Security already configured and users are stored in DB):
1 Turn on remeber-me in the conf :
<http>
...
<remember-me data-source-ref="yourDataSource"/>
</http>
2 Create corresponding table in the database:
create table persistent_logins (username varchar(64) not null, series varchar(64) primary key, token varchar(64) not null, last_used timestamp not null)
3 Add corresponding checkbox to your login form:
<input id="rememeberMe" type="checkbox" name="_spring_security_remember_me">
In a case of REST you need to adjust third step according to your authentication scenrio.
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>
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.
The JDBC realm specifies a table structure for authentication which contains the columns defined by the attributes userNameCol and userCredCol. These correspond to user and password which makes sense for FORM or BASIC auth-methods. They are interactive and require these two pieces from the client's user.
What comes back from the
certificate?
What would an example of the data
stored in userNameCol and
userCredCol look like?
Is there an alternative table
structure for the realm in this
case?
PS - I'm using tomcat 5.5.x.
JDBCRealm Supports CLIENT-CERT
Yes, it can. However, there are few quirks to watch out for.
User Names
The user name column should contain the certificate subject's distinguished name, as a character string. Unfortunately, the method Tomcat uses to obtain this string produces an implementation-dependent result, so it's possible if you were to switch to a new security provider or even just upgrade your Java runtime, you might need to map your user names to a new form. You'll have to test your deployment to find out what format is used.
Specifically, getName() is called on the Principal returned by X509Certificate.getSubjectDN() to obtain a String, which is used as the user name. If you read the documentation, you'll find that this is no longer the best approach.
Authentication
The simplest set up would be to load your trust anchors into Tomcat's trust store, which is configured in the "server.xml" file. With this setup, any client certificate chain that is root in one of your trusted CAs will be considered "authenticated," and rightly so—authentication means that an identity is known, and is distinct from authorization, which determines what that identity is allowed to do.
Authorization
Since anyone with a signed certificate will be authenticated, you need to set up roles in order to protect private resources in your application. This is done by setting up security constraints, associated with roles, in your "web.xml" file. Then, in your database, populate the "roles" table to grant trusted users with extra roles.
The relationship between the user table and the roles table works exactly as it would with FORM-based authorization, and should be utilized to grant appropriate permissions to users that you trust.
A Note on Passwords
The JDBCRealm will create a new Principal, which does carry a password, but unless your application downcasts this Principal to the Tomcat-specific implementation (GenericPrincipal), this property won't be visible to you, and it doesn't really matter what you put in that column. I recommend NULL.
In other words, when using JDBCRealm with client-auth, the password field is ignored. This GenericPrincipal has a method to access an underlying principal, but unfortunately, the Principal from the certificate is not passed along; the JDBCRealm will set it to null; the only useful method in this scenario might be getName() (returning the subject DN is some possibly non-standard form).
Table Structure and Content
Use exactly the same table structure you would for a FORM-based JDBCRealm (or DatasourceRealm). The only difference will be in the content. The user name will be a text representation of the subject distinguished name, and the password will be NULL or some dummy value.