This content has been marked as final. Show 11 replies
I didn't read through all the blog links you provide so forgive me if I reply something you already know. Actually ADF Security is expected to work such that if you deploy ADF Security to the default security provider and it works, then re-configuring WLS to use another authentication provider should work the same. The one area for errors I see is the class for Groups and users in WLS, which I am not sure - because I haven't tested - always is mapped to the WLS user and group principals (weblogic.security.principal.WLSGroupImpl)
As you say I kind of figured that once the Active Directory authenticator is up and running, it should just slot straight in. Beyond being able to see the users and groups drawn from the AD server in the WLS console myrealm, I'm not aware of any other way to work out is it probably configured? WLS doesn't seem to log anything about security failures, so it's hard to know what's going on. I've used Wireshark to watch the WLS LDAP queries against AD, and as far as I can see it's doing the right thing and getting a positive response. What it does with it beyond there I don't know.
Maybe this would be better addressed on the WLS forum, but I figure the ADF Security makes it an ADF issue until we determine I've done everything correctly in JDev.
Regards the class for groups & users in WLS, beyond making the changes to the system-jazn-data.xml file as described in Steve's post about manually migrating the security settings, is there anything else I need to do? As you're indicating here, we shouldn't need to change the jazn-realm element from jazn.com to myrealm?
I note you based your jazn-data.xml on Edwin's blog post. I think Edwin may have made a mistake in suggesting we need to configure myrealm into the jazn-data.xml file, I think by myrealm is the default realm under WLS so it should always be used(?). Dunno, hoping Frank can confirm as per my previous post.
Also check out the link to Steve Muench's article above. This is an important step in migrating your ADF security settings to WLS. Real shame JDev 11g doesn't do this by default (hint hint Oracle). I'm in the process of writing up a blog post, pending the output of this thread, that will hopefully assist in describing all the steps necessary to get this going.
Hi,1 person found this helpful
By doing as I have described in my blog - http://andrejusb.blogspot.com/2009/01/practical-adf-security-deployment-on.html I was able to authenticate and authorize against Default Authenticator Provider and against LDAP also.
I was using in my blog, terms - Enterprise and Application roled, based on Frank Nimphius ADF Security Authorization - http://www.oracle.com/technology/products/jdev/tips/fnimphius/adfsec_camt3/ADF%20Security%20-%20Authorization.htm
With LDAP you just authenticate and there shouldn't be any difference for authorization from where role list will come.
I noticed couple of times, ADF Security is not working, when there is no Model (ADF BC) available in application. At least I'm sure for 100%, security EL expressions are not working if ADF BC Model is not created in your application - strange...
Regarding automatic Policy migration, it works only during first deployment of application from JDeveloper (strange again). If later you change jazn-data.xml and deploy again, changes will not be migrated. If you deploy from Ant or directly on WebLogic, Policies are not migrated. So, manual migration is more stable. In our project we are invoking it from Cruise Control.
We have successfuly migrated security policies to standalone WLS by following policy migration instructions from the already mentioned link, but with addition of one extra step. We had to manualy copy realm roles (role + guid tags) from application jazn-data.xml to system-jazn-data.xml, and only then the security started working, so you might consider that as an option.
Strange thing, though, is that copying of <guid> didn't make any problems, doesn't make sense.
Edited by: Pedja on 14.01.2009. 19.34
Thanks for the suggestion Pedja. I tried copying in the following into the system-jazn-data.xml:
... with no success, and even tried with the WLS default realm name "myrealm" as follows:
<jazn-realm default="jazn.com"> <realm> <name>jazn.com</name> <roles> <role> <name>Corporate Services</name> <guid>8FE12F91E1DB11DD9F5381AD1AA44422</guid> <members/> </role> </roles> </realm> </jazn-realm>
... also with no success.
<jazn-realm default="myrealm"> <realm> <name>myrealm</name> <roles> <role> <name>Corporate Services</name> <guid>8FE12F91E1DB11DD9F5381AD1AA44422</guid> <members/> </role> </roles> </realm> </jazn-realm>
I was starting to suspect the problem is with the WLS-Active Directory integration in my case, but I don't think I can assume that yet. When I login with a user from the AD server, I don't see the error-login page, but rather a 403 forbidden page. This seems to indicate that the user is being correctly authenticated from the AD server's users, but the role retrieval is not working correctly. However given that the user should now be authenticated for the session, a requery on the same protected page should return the 403 forbidden page again rather than the login page as the user should already be authenticated, but instead I get the login page again.
I've been hunting around in the WLS logs to see if it actually logs these failures with no success.
This afternoon I'm going to give an openLDAP authenticator a go.
Correction, I've been looking at the WLS logs in the WLS console, and it's not showing anything. Instead accessing the log file directly I see:
172.21.212.43 - - [15/Jan/2009:12:35:28 +0900] "GET /TestStandaloneWLSSecurity-ViewController-context-root/faces/ViewClientNames.jspx HTTP/1.1" 302 547
172.21.212.43 - - [15/Jan/2009:12:35:28 +0900] "GET /TestStandaloneWLSSecurity-ViewController-context-root/adfAuthentication;jsessionid=6W25JnvQT37FZQRktfhd7XSJwLJ5zpy8H21QgjnvsLjHPX3JwJX5!1285830724 HTTP/1.1" 302 375
172.21.212.43 - - [15/Jan/2009:12:35:28 +0900] "GET /TestStandaloneWLSSecurity-ViewController-context-root/login.html HTTP/1.1" 304 0
172.21.212.43 - - [15/Jan/2009:12:35:33 +0900] "POST /TestStandaloneWLSSecurity-ViewController-context-root/j_security_check HTTP/1.1" 403 109
As such you can see my attempt to access the original page, of which the adfAuthentication servlet comes into play in the 2nd log entry, redirects me to the login.html page, where I log in, then the 403 forbidden response.
The only log entry in my server log file:
####<15/01/2009 12:35:28 PM WST> <Info> <ServletContext-/TestStandaloneWLSSecurity-ViewController-context-root> <DTFW16090> <ADFServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1231990528944> <BEA-000000> <[JpsWlsFilter.doFilter] setContextID to TestStandaloneWLSSecurity_application1>
I've figured it out in my case.
In Frank's blog entry regarding setting up OID against WLS, in the very last part of his blog entry, he says set the WLS OID Authenticator Control Flag = Sufficient. While I'd done this, it's also necessary to re-order the Authenticators such that your custom authenticator occurs before the 2 default authenticators DefaultAuthenticator and DefaultIdentityAsserter.
Brain now fried.
I'm going to write all of this up in a blog entry and post today or tomorrow to assist others.
Thanks for your assistance.
My blog post can be found here: [Configuring a JDev 11g ADF Security app on standalone WLS against MS Active Directory|http://one-size-doesnt-fit-all.blogspot.com/2009/01/configuring-jdev-11g-adf-security-app.html]
Hopefully useful to future readers.
In Frank's blog entry regarding setting up OID against WLS, in the very
last part of his blog entry, he says set the WLS OID Authenticator
Control Flag = Sufficient. While I'd done this, it's also necessary to
+re-order the Authenticators such that your custom authenticator occurs before the 2 default authenticators DefaultAuthenticator and DefaultIdentityAsserter.+
And that extra step is the one I forgot to mention, could have saved you some time and brain cells. :)
You are correct. The providers are chained. I solved it by setting the default authenticater also to sufficient. That way if either provider can authenticate a user it passes.