aspose file tools*
The moose likes Websphere and the fly likes User Authentication Mechanisms - Can you use a local file? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of JavaScript Promises Essentials this week in the JavaScript forum!
JavaRanch » Java Forums » Products » Websphere
Bookmark "User Authentication Mechanisms - Can you use a local file?" Watch "User Authentication Mechanisms - Can you use a local file?" New topic
Author

User Authentication Mechanisms - Can you use a local file?

Corey McGlone
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
I've been playing with my WAS configuration and, normally, when we do user authentication, we go against LDAP. That works fine, but it requires me to have a valid username and password that exists in LDAP. For me, that gives me exactly one user that I can use to log in to my application - me. I'd like to be able to log in as multiple users that I can assign different roles to.

In using Tomcat, I found that Tomcat's basic authentication mechanism is a simple xml file named tomcat-users.xml. From there, you can define usernames, passwords, and roles in a very simple format. If you need to add, remove, or modify users, you simply adjust that file and restart your server. While this certainly wouldn't be a good option for a production environment, it's just about ideal for a development environment.

Anyway, I've been trying to find a way to do something like this in WAS, but I simply can't find a way to do it. I've been trying to search through documentation and what-not, but I just can't find any reference to it. Anyone know of a way that I can get WAS to do this?

For reference, I'm running WAS 6.0.2.5.

Thanks,
Corey


SCJP Tipline, etc.
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30894
    
158

Corey,
Isn't there a flat file option? I know WSAD 5 had this. I'm not sure about RAD/WebSphere 6 though.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968
    
    1

Essentially, you must have users on your LDAP tree that you can assign rights to. It's a multi-step process, but it's not too overwhelming.

I put together a multimedia tutorial on configiring LDAP with WebSphere, and doing subsequent J2EE role to LDAP User mappings.

Enjoy the tutorial:

Configuring an LDAP Server with WebSphere Application Server and Turning on Security

-Cameron McKenzie
Corey McGlone
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
Originally posted by Jeanne Boyarsky:
Isn't there a flat file option? I know WSAD 5 had this. I'm not sure about RAD/WebSphere 6 though.


Okay, so I got halfway through writing a response to you and got an idea of a new place to look. I did some more digging and I've found the answer on how to authenticate against a flat file. Here's the basic idea:

Under Global Security, change your user registry to "Custom"
You'll have to go into the "Custom registry" settings and make some changes
- The sample registry class IBM provides with WAS 6 is named "FileRegistrySample.java"
- Add two custom properties that follow this format:
-- usersFile = path to file named users.props (Details here)
-- groupsFile = path to file named groups.props (Details here)

Once that's in place, you can add/remove/edit users from those two files and authenticate against them.
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30894
    
158

Corey,
Thanks for sharing the details. I know my response was on the vague side, but that was all I remembered. I just hoped it would be better than saying nothing!
Corey McGlone
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
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 ]
    Jeanne Boyarsky
    author & internet detective
    Marshal

    Joined: May 26, 2003
    Posts: 30894
        
    158

    Corey,
    Thanks again. I'm printing this out as we speak. You should write an article

    This is so useful to know that I almost forgot I didn't have a question originally!
    Cameron Wallace McKenzie
    author and cow tipper
    Saloon Keeper

    Joined: Aug 26, 2006
    Posts: 4968
        
        1

    Wow...That information is golden.

    Why can't online tutorials be as simple and straight forward as that?

    Thanks!

    -Cameron McKenzie
    munna Happy
    Greenhorn

    Joined: Oct 15, 2010
    Posts: 1
    Hi Corey McGlone,

    good job Corey.

    I had implemented the global security by following your instructions.But it was not authenticating all the users which I had mentioned in the users.props file only authenticating the user which i mention in serverid on custom properties page.

    WAS v6.0.2.31.

    I understood all the steps except.....

    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


    I will really appreciate if you respond ASAP.

    Thanks.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: User Authentication Mechanisms - Can you use a local file?