User registration with declarative security

[joe543]

Hi,

I have a question regarding how one could create a user registration process in an environment where security is implemented declarativley.

Assume we are creating a typical web application which maintains a db of users running with tomcat+jboss. If I want to store my user accounts in a db - perhaps persisting the data as an entity bean, and I want to use declaritive security, how do I control adding new users(with their usernames and passwords) to the system automatically? In other words how do I inform the container that a new user has just been added?

There must be some way in which the auth.conf can be updated by the new users.

I'm a little confused here. Please help.

Thanks
Joe

[luke_t]

>how do I control adding new users(with their usernames and passwords) to the system automatically?

J2EE doesn't have anything to say about how local security is implemented, so how you store/create/manage accounts i up to you. If you're using a database, then just create a new entry.

> In other words how do I inform the container that a new user has just been added?
This doesn't make sense. The container doesn't really have to know anything about users. If you create a new entry in the security database and that user logs in, then the login module will allow them access just as any other.


> There must be some way in which the auth.conf can be updated by the new users.

Auth.conf has nothing to do with specific user information, so you shouldn't need to update it.

Luke.

[joe543]

Hi,

What I'm getting at is the following:

Depending on the login module, usernames and passwords (and roles) can be stored in users.properties and roles.properties or they can be stored in database tables (DatabaseServerLoginModule - which is an example of a custom way to authenticate a user).

If I am using database tables to store my app's customer account information (which includes username and password) should I be maintaining two seperate sources for user data or can I share the datasources between DatabaseServerLogin and Account entity bean?
If I understand correctly, it would be silly to use the two files (users.properties and roles.properties) to maintain username and passwords if I am going to be using a database for persistence storage for my customer account data anyway. Wouldn't it represent a conflict if usernames and passwords were being maintained twice seperately?

(I've got a sneaky feeling thats what you've been trying to say - can you confirm?)

I'm assuming that with users.properties and roles.properties, one cannot adjust this data dynamically from the application level.

Thanks Luke!;-)
Joe

[wchao]

Let's say you have two tables: account and user_role_tbl.

account looks like this:
account_id int,
username varchar(16),
password varchar(16),
... other fields ...

user_role_tbl looks like this:
username varchar(16),
user_role varchar(16),
... other fields ...

You could have the Account entity bean mapping to the account table, which also stores the username and password for each user of the application. For JBoss-managed authentication, you'd just need to configure auth.conf like so:

principalsQuery="select password from account where username=?"
rolesQuery="select user_role, 'Roles' from user_role_tbl where username=?"

You need the 'Roles' column for JBoss 2.4 according to the PDF documentation you can purchase (page 263).

There's no need to maintain a users.properties and roles.properties. In fact, it's kind of silly given that you already have a table set up for users and given that using a database allows for easy changes to the user and role information.

[joe543]

Thanks for that!

Joe

[luke_t]

OK, you never mentioned that you were using the properties files in your first post. You were talking about modifying auth.conf which is something else altogether and doesn't store user information.

The UsersRolesLoginModule is intended for test systems and so on, so isn't something you should be using to maintain user accounts seriously and updating it dynamically wouldn't be desirable.

Your security information doesn't need to be in the same database as your customer account data and you wouldn't have to maintain the user/password info twice. When you create a new account, you create an entry in the security database as part of the transaction that creates the other account data.

Luke.

[joe543]

Yes, I must admit - I had my question well hidden!
Thanks for your help, though!(and patience):-)

Joe