Originally posted by Jeanne Boyarsky:
Thanks for sharing the details.
Some more details for you - I did a write-up and put it in our wiki here in the office. Here's that write-up:
----------
Okay, so I did a little more poking and think I may have finally come up with an answer to what I wanted to do. At least it appears to be working the way I want. Follow these instructions if you want to authenticate against a flat file, as opposed to LDAP. Keep in mind that this is really only for local development - in production, you certainly want to go against something more robust. Of course, the really cool thing is that you can keep your production servers pointing to LDAP and your local server pointing to your local file and your application is none the wiser. You just need to keep it straight in your head which user ids and passwords you're using.
Create a directory named "localAuthentication" in your WAS install path Mine is at C:\Program Files\IBM\Rational\SDP\6.0\runtimes\base_v6\profiles\default\localAuthentication
In that direcory, create two files, named users.props and groups.props (details about the formats can be found below) Open the administrative console Under "Security", click on "Global Security" On the right side, under "User Registries", click on "Custom" Enter a username and password here that you want defined in your custom registry (I used corey/corey, for example) The "Custom registry class name" should read: com.ibm.websphere.security.FileRegistrySample Mine was defaulted to this
Click on "Custom properties", on the right Add the following two properties: usersFile = ${USER_INSTALL_ROOT}/localAuthentication/users.props
groupsFile = ${USER_INSTALL_ROOT}/localAuthentication/groups.props
Save all changes and return to the Global Security page In the "Active user registry" section, select "Custom user registry" Save changes and close the admin console Double-click your server to view the Server Overview Under security, set the User ID and Password to the same username and password you defined on the Custom Registry page (corey/corey, for me) Save changes Restart the server Those steps should get you authenticating against a flat file, instead of LDAP. Personally, I think it's very nice for development.
Essentially, this is telling WAS to use a
Java class that implements the UserRegistry interface to handle authentication. You can write your own class to do this, but the "demo" class that IBM provides, FileRegistrySample, actually reads a file for authentication, which is really what I wanted. You can find the full source code for FileRegistrySample.java
here.
This class uses two files to do the authentication and authorization. I don't think we'll be in a situation in which we can use J2EE security for authorization, so the authentication part of this is the most important, to me. The
users.props file contains all the usernames and passwords that you want to define in it. Here is the format:
<pre>
# 5639-D57, 5630-A36, 5630-A37, 5724-D18
# (C) COPYRIGHT International Business Machines Corp. 1997, 2005
# All Rights Reserved * Licensed Materials - Property of IBM
#
# Format:
# name :p asswd:uid:gids
isplay name
# where name = userId/userName of the user
# passwd = password of the user
# uid = uniqueId of the user
# gid = groupIds of the groups that the user belongs to
# display name = a (optional) display name for the user.
corey:corey:1:567:
dave
ave:2:567:
bob:bob:3:567:
ethel:ethel:4:567:
</pre>
In this case, I've defined 4 users - all in the group 567. What is group 567, you ask? Take a look at
groups.props to find out:
<pre>
# 5639-D57, 5630-A36, 5630-A37, 5724-D18
# (C) COPYRIGHT International Business Machines Corp. 1997, 2005
# All Rights Reserved * Licensed Materials - Property of IBM
#
# Format:
# name:gid:users
isplay name
# where name = groupId of the group
# gid = uniqueId of the group
# users = list of all the userIds that the group contains
# display name = a (optional) display name for the group.
admins:567:corey,dave,bob,ethel:Administrative group
</pre>
In groups.props, you define the groups you want to define, along with the users that belong to those groups. There is some redundancy between the two files, but the system does work as it is.
One very cool thing I found is that this custom registry class reloads the authentication every time you try to authenticate a user. While this seems grossly inefficient, it means that you can add/remove/modify users and have those changes reflected immediately, without having to restart your server. Again, awesome for development.
You can find some additional information
here.
[ May 04, 2007: Message edited by: Corey McGlone ]
