ADF integration with AD

My assumption is

you don't want to use ADF security and weblogic configuration of ldap.

1. Get username/password from login form in your bean. Technology Blog: ADF: Programatic user authentication instead of j_security_check (Password retrieval )

2. Validate username/password using javax.naming apis. http://stackoverflow.com/questions/2172831/how-do-a-ldap-search-authenticate-against-this-ldap-in-java

    [you can use OPSS also I think to validate username/password but I am not very sure if you can use opss without any configuration in weblogic]

If you don't find api to validate username/password in javax.naming package, I would say try making connection to ldap using loggedin user/password and if its successful, it means username/password is correct otherwise may be wrong. You can view exact exception message and then conclude.

Before doing this you must need to ask yourself.

1. How are you going to make sure that if any page user tries to access, he should be redirected to login page if user is not authenticated and page is secured? May be a phase listener can help here?

2. I would still say if possible use ADF provided security features. You will get all this out-of-the-box. Only thing you need to configure weblogic provider.

Thanks

Sanjeev.

First thing ADF does not have any user/role.

If you are thinking of user/role you create while configuring ADF security, they are test users/role and they also get created in embedded ldap of weblogic while you deploy your application. This embedded ldap is preconfigured in weblogic security realm.

For users/role, ADF rely on weblogic configuration of provider.

Now answer to your question

1. You don't need OID if you have AD. They both do same thing. They both manage user/password and groups. If client has AD, we generally directly configure AD as provider in weblogic security realm. In your case you don't want to do weblogic configuration so I will ask you to pragmatically validate username/password using javax.naming.

2. Your javax.naming directly calls AD so if a new user is there javax.naming will directly refer and validate it from there.

3. There is no group in ADF. ADF refer to weblogic security realm configuration for groups. If you are referring to ADF enterprise role then yes there name must match with AD group name. But that is only if you decide to go with ADF security and it will require you to configure weblogic.

Here is how ADF-security works in general

You enable security for your ADF application. As part of this a jazn file gets created.

In this file you mention which resource (page/task-flow) is secured. You also sepcify which application-role can view that resource.

You create enterprise roles in jazn file and map them in application role.

Effectively you are saying Enterprize role (manager) has access to Application role (APP_Payroll_Manager, APP_learning_Manager etc). App_Payroll_Manager application role has access to payroll related pages.

Forget about creating test users in jazn. They simply gets created in embedded ldap of weblogic which is already configured so that a developer can directly start using those users.

Till now you do not have actual users and their groups anywhere mentioned.

Now you go to weblogic and configure your security realm. Here you can attach AD or OID or and LDAP which stores user/role information. NOTE: You can directly configure AD in weblogic without any need of OID.

weblogic will always refer to these configured AD or OID for latest user/group information. Your group name of AD must match with enterprise-role name mentioned in jazn file.

Ideally there is only one set of users/groups and that is mentioned in AD. Everybody is looking there for source of truth. No need of any syncing.

Above mentioned scenario is if you decide to use ADF security and I would encourage you to do so.

Now if you don't use ADF security then also you should look for AD for source of truth but you need to rely on your implementation.

As I said

you need to decide which all pages are secured and have that information somewhere in a file (may be a property file)

In ADF phase listener you need to check which page user is accessing. If its secured then you need to redirect him to login page.

Have a bean for login page and get username/password as shown in above blogs. Once you have username/password use pure javax.naming apis to connect with AD directly. You need to read AD configuration from a property file and then use javax.naming apis. If you successfully gets connected it means username and password is correct.

Hope this help

/* Dont hesitate to mark correct/helpful if you find so */

Thanks

Sanjeev.

Just saw few of your concerns and here is my take.

1. You said admin can't do much post deployment.

Sanjeev: This is not correct. If you have enterpise manager. You can change almost everything that you mentioned in jazn. You can define new policy for resources. Like which application role is going to secure which resource. You can change mapping of enterprise-role and application role. As I said users/groups are always in AD (source of truth) so you should change them there only. They are not even mentioned in jazn if you leave test users aside.

2. Weblogic admin should not be able to see application user

Sanjeev: Yes he can see them but he can't change anything. He cant create/edit/delete details of these users. For that someone needs to got to AD. I do not see it a security threat. Yes you may want to make sure that AD authentication is set as required in provider configuration otherwise weblogic admin can create user in embedded ldap and provide them sufficient role. (But yes he can anytime change that required setting as well. So yes with embedded ldap in place, weblogic admin is security threat for application. My question to weblogic security experts would be "Is there a way to make sure that weblogic admin is not able to use embedded ldap? Sorry I don't know about it.)

/* Dont hesitate to mark correct/helpful if you find so */

1. Using EM weblogic admin can do stuff but not end user. He can only change information of jazn.

    In jazn we don't have user information (leave test users aside), we don't have user and group mapping. So these information can not be changed using EM.

    What we can change is --> Application role to resource mapping. Enterprise role to Application role mapping.

    Ideally saying which resource (page) can be accessed by which application role/enterprise role that is called policy and that policy can be defined at runtime using EM console by weblogic admin.

   User and their group mapping resides in AD and we should change them in AD only. EM console can not do it.

   I have seen usecases where end user want ability to create new user and assign then a group through ADF UI so that they can manage whole user management using ADF screen. We achieved it using OPSS apis. In a nutshell you need to configure your weblogic security policy for active directly. Then you need to write OPSS apis to search-user/create-new-user/assign-user-to-a-group. Then you need to create ADF pages which will use these OPSS apis.

2. This is my guess: While configuring AD provider in weblogic if you make that as required, I believe weblogic admin will not be able to login to application. But you need to check if he is still able to login to weblogic console.

Thanks

Sanjeev