Problems with use of security realm with custom authentication provider???

[Kelly Dolan]

I installed WebLogic 8.1 and created a basic domain. Within this domain, I see the standard security realm 'myrealm' with all of the defaults.

I have an application that I need to deploy and authenticate to its user database. I implemented a custom authenticator based on the samples found and instructions given and have actually confirmed it works.

I think the ideal situation for me is to leave 'myrealm' as the default security realm and to create a new security realm 'myapp' that will be used my application to authenticate users (via the custom authenticator). My reason for this is that if I deploy multiple applications, I may want to authenticate users differently for each.

So here's my problem...

If I make 'myapp' the default security realm, my application successfully authenticates users. If I do not make 'myapp' the default security realm, WebLogic tells me it cannot find 'myapp' when it tries to deploy the EAR.

In my EAR file, I've set <realm-name>myapp</realm-name> in two places. One in the WAR web.xml with the login configuration parameters and one in the EAR weblogic-application.xml with the security configuration parameters.

Am I not understanding something? Is this how it is supposed to work (e.g., use the default realm only)? Do I need to do something differently with the deployment descriptors?

I'm new to WebLogic so any and all suggestions are greatly appreciated. Thanks!

- Kelly

[Scott Dunbar]

Kelly,
A couple of things.

Authentication and authorization providers are really system level things. They are defined at the server level, not at the enterprise or web app level. As such you will need to code for that. I could see an installation that has a different authenticator and authorizer for each application and does the correct thing as needed.

From the authentication side, for the DefaultAuthenticator and your custom authenticator, what are the control flags? These are flags that tell the adjudicator how to handle failures in any of the string of authenticators. You will want both the default and your authenticator to be set to "sufficient". That tells the adjudicator that either the default or your authenticator can say "yes, this person is allowed to log in" and the login will work.

In general I would leave the DefaultAuthenticator around - it handles access to the embeded LDAP server and things like the "weblogic" user are stored in there.

[Kelly Dolan]

Thanks! This is helpful.

You stated you could see an installation that has a different authenticator and authorizer for each application and does the correct thing as needed. How would this look to the configuration? Would it be one default security realm that contains a set of "sufficient" authenticators, etc.? How would each application (e.g., EAR) indicate which authenticator to use? Or am I still missing something?

Kelly

[Scott Dunbar]

Originally posted by Kelly Dolan:
You stated you could see an installation that has a different authenticator and authorizer for each application and does the correct thing as needed. How would this look to the configuration? Would it be one default security realm that contains a set of "sufficient" authenticators, etc.? How would each application (e.g., EAR) indicate which authenticator to use?

Let's look at this in two parts, authentication and authorization.

For authentication, WebLogic uses "global" users. That is, if the user "bob" is defined anywhere within any authentication provider then "bob" is a valid user, potentially able to log into something. Some people partition this namespace by having their application have a hidden field to indicated, say, department. But most just accept the global namespace and use something like email address. The point is that application A may want to authenticate users from database A while application B may want to authenticate users from database B. In that case you may want to have two different authentication providers, one for A and one for B.

But now it gets, um, fun. Say "bob" is defined in both databases but his password is different in the two db's. You've created authenticatorA and authenticatorB. If they, along with the default authenticator have their control flags set to "sufficient", then bob will be able to log in with either password(!). That is because one of the authenticators said "yes, let him log in" and so he can.

That is where the authorization providers can help some. The authorization provider looks at both the Subject (i.e. "bob") and the resource that bob is trying to access (for example, a method on an EJB). This information, coupled with the roles that bob is in can then be used to determine if bob should have access to something.

The good part is that once you have an authorization provider is that you use regular EJB security to manage it.

It's a bit of a pain. But the important part is that names and roles (i.e. anything that is a javax.security.auth.Subject) are global in nature, at least to a single instance of WLS.
[ October 22, 2004: Message edited by: Scott Dunbar ]