Weblogic 8.1 JAAS login.configuration.provider from java.security does not seem to work?

Question

We configure a custom implementation of the JAAS
javax.security.auth.login.Configuration class for our applications security
framework in JRE_LIB/security/java.security using the entry
login.configuration.provider=com.foo.SecurityConfiguration
However, this does not seem get picked up and the configuration provider
class instead seems to default to
weblogic.security.service.ServerConfiguration
instead.
Has anyone else seen this?
We're using the JDK bundled with Weblogic 8.1
TIA for your help

Answer 1

Thanks for all the posting re. this issue....
I think the way Weblogic implemented "support" for JAAS in 8.1 totally
blows. In fact, when I asked BEA support about this, they basically sent me
an email saying that "Weblogic owns the JAAS configuration" so if you have a
security framework that is application server agnostic, but leverages JAAS
then you are screwed when deploying on Weblogic 8.1.
I looked for a workaround and believe that instead of using an entry in
java.security for your custom configuration class, if you set the JVM
parameter
-Dlogin.configuration.provider=com.foo.SecurityConfiguration
then what happens is that the Weblogic custom class
weblogic.security.service.ServerConfiguration is invoked by JAAS. It tries
to load the login module configuration and if that fails, it delegates to
com.foo.SecurityConfiguration. So this should enable both the weblogic
security framework and a custom security framework that are both based on
JAAS
I'm currently testing this out
"Lloyd Fernandes" <[email protected]> wrote in message
news:[email protected]...
>
Robert Greig <[email protected]> wrote:
Lloyd Fernandes wrote:
"Lloyd Fernandes" <[email protected]> wrote:
"Prashant Nayak" <[email protected]> wrote:
We configure a custom implementation of the JAAS
javax.security.auth.login.Configuration class for our applications
security
framework in JRE_LIB/security/java.security using the entry
login.configuration.provider=com.foo.SecurityConfiguration
However, this does not seem get picked up and the configuration
provider
class instead seems to default to
weblogic.security.service.ServerConfiguration
instead.
Has anyone else seen this?
We're using the JDK bundled with Weblogic 8.1
TIA for your help
As per documentation in the API JAVADOCS forjavax.security.auth.login.Configuration
>>>>
>>>>
The default Configuration implementation can be changed by settingthe
value of
the "login.configuration.provider" security property (in the Java
security
properties
file) to the fully qualified name of the desired Configurationimplementation
class. The Java security properties file is located in the file named
<JAVA_HOME>/lib/security/java.security,
where <JAVA_HOME> refers to the directory where the JDK was installed.
Have you tried to use a startup class to set the configuration providerusing
javax.security.auth.login.setConfiguration(YourConfigClass);
Weblogic probably uses this to set the configuration class to it'sown.
You have to consider whether this is really something you want to do
however. If you want to get WLS to use a custom authenticator use its
SSPIs. You can configure the order etc. in the admin console.
By overriding the configuration you override it for the server as a
whole which can mean for example that you cannot login to the admin
console. Having said this, from memory, I believe that the property is
ignored in WLS. However you can still call
Configuration.setConfiguration if you really want to.
The fact that there is a "global static" in the Configuration class is
a
Bad Thing IMHO, that was never really designed for an app server
environment.
Robert
If it is a bad thing to have a static how come Weblogic uses it instead ofthe
standard way of modifying the property in java security file - it isbecause
weblogic wants it's own way of implementing instead of using using the'plugable
module' architecture of JAAS.
When weblogic advertised that it will support JAAS the impression was thatWeblogic
would provide a login module that will implement the security mechanism itwanted
- instead it went it's own way.
Also consider the following
1. JAAS specifies a mechanism for multiple configurations based on a'application'.
This is not possible in the current 'weblogic security mechanism'
2. Weblogic says it supports JAAS but what it does not tell you is that inorder
to use available login modules you have to write a whole bunch of code tosupport
principal validators and authenticators. (I begin to wonder if write oncedeploy
anywhere is not part of Sun's certification process anymore)