Weblogic 10.3: Webapp security using web.xml and DB roles inside WLS console_问答_开发者

Scenario

We are using Weblogic Server 10.3.4 to run our webapp which has security constraints enabled in order to require a user to sign in before he/she can use the application. The user and group information shall reside in the application database, the authentication shall be handled by WLS (the container).

I have set up a database schema as described in this blog article, set up a new Security Realm "app.realm" in WLS console and defined a SQLAuthenticator inside it.

After having restarted WLS I can see my user and group definitons from the database in "app.realm" in the WLS web console. The user I am trying to authenticate is member of the WEBAPP_USER group (I see the group membership on the user's detail page in WLS console).

When I deploy the application (using standard settings, no adjustments in the WLS web console) and call a protected URL, I am redirected to the login.html form as expected. However, no matter what I try, entering the (right) password always yields authentication failure sending me to the login_error.html page. For debugging purposes, I have enabled plain text passwords in my SQLAuthenticator, so I am pretty sure having used proper credentials.

I already saw these two threads, but neither seems to help with my problem.

Update 1

Thanks to emzy's comment I now see that WLS is checking the credentials against the default realm "myrealm" and tries to resolve the login username against the embedded LDAP:

...
####<20.04.2011 09:29 Uhr MESZ> <Debug> <SecurityAtn> <hostname> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1303284573150> <BEA-000000> <getDNForUser search("ou=people,ou=myrealm,dc=nvs_dev", "(&(uid=app.user)(objectclass=person))", base DN & below)>
####<20.04.2011 09:29 Uhr MESZ> <Debug> <SecurityAtn> <hostname> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1303284573150> <BEA-000000> <DN for user app.user: null>
####<20.04.2011 09:29 Uhr MESZ> <Debug> <SecurityAtn> <hostname> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1303284573150> <BEA-000000> <returnConnection conn:LDAPConnection { ldapVersion:2 bindDN:""}>
####<20.04.2011 09:29 Uhr MESZ> <Debug> <SecurityAtn> <hostname> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1303284573151> <BEA-000000> <javax.security.auth.login.FailedLoginException: [Security:090302]Authentication Failed: User app.user denied
        at weblogic.security.providers.authentication.LDAPAtnLoginModuleImpl.login(LDAPAtnLoginModuleImpl.java:229)
        at com.bea.common.security.internal.service.LoginModuleWrapper$1.run(LoginModuleWrapper.java:110)
        at java.security.AccessController.doPrivileged(Native Method)
        ...

Update 2

I now performed these steps and get the authentication to work:

Add the SQLAuthenticator to the default realm "myrealm" in WLS console
Set both Weblogic's DefaultAuthenticator and the new SQLAuthenticator as SUFFICIENT in the respective provider settings (the "JAAS control flag" how they call it)
Restart WLS

One questions remains, though:

Questions

~~Does WLS have some additional logging besides the standard log files in the <domain>/server/AdminServer/logs folder where I can see what happens?~~
~~What am I doing wrong / What part in the puzzle am I missing to get my form-based authentication to work with my application?~~
Why does WLS use "myrealm" for authentication when I am giving "app.realm" explicitly in my web.xml?

Here are my configuration details:

web.xml

...
<security-constraint>
  <web-resource-collection>
    <web-resource-name>Webapp Platform</web-resource-name>
    <url-pattern>/*</url-pattern>
  </web-resource-collection>
  <auth-constraint>
    <role-name>USER</role-name>
  </auth-constraint>
  <user-data-constraint>
    <transport-guarantee>NONE</transport-guarantee>
  </user-data-constraint>
</security-constraint>
<login-config>
  <auth-method>FORM</auth-method>
  <realm-name>app-realm</realm-name>
  <form-login-config>
    <form-login-page>/login.html</form-login-page>
    <form-error-page>/login_error.html</form-error-page>
  </form-login-config>
</login-config>
<security-role>
  <description>Standard user</description>
  <role-name>USER</role-name>
</security-role> 
...

weblogic.xml

<wls:weblogic-web-app xmlns:xsi="http://www.w开发者_运维知识库3.org/2001/XMLSchema-instance"
  xmlns:wls="http://www.bea.com/ns/weblogic/weblogic-web-app"
  xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd http://www.bea.com/ns/weblogic/weblogic-web-app http://www.bea.com/ns/weblogic/weblogic-web-app.xsd">
  ...
  <security-role-assignment>
    <role-name>USER</role-name>
    <principal-name>WEBAPP_USER</principal-name>
  </security-role-assignment>
</wls:weblogic-web-app>

login.html

<html>
<head>
<title>Login</title>
</head>
<body>
<form method="POST" action="j_security_check">
<table>
<tr><td>Username:</td><td><input type="text" name="j_username"></td></tr>
<tr><td>Password:</td><td><input type="password" name="j_password"></td></tr>
<tr><td colspan=2 align=right><input type=submit value="Submit"></td></tr>
</table>
</form>
</body>
</html>

that's a tricky concept with the auth realms. Regarding your last open question: - Why does WLS use "myrealm" for authentication when I am giving "app.realm" explicitly in my web.xml?

You can configure multiple security realms in WebLogic, however only ONE can be active ( in this case the default myrealm). That is one of the annoying limitiations unofrtunately Inactive ones are not used at all. Referencing an inactive realm in web.xml have no effect.

look here http://docs.oracle.com/cd/E24329_01/web.1211/e24422/overview.htm#i1093279

Under the Server -> Debug tab on the console, you can enable debug/trace level logging. I would try enabling all of the security related logs to see if shows any warnings or exceptions.