We have integrated FileNet along with our J2EE application. Our application uses SSO to login into the application. The application maintains users,roles and the access privileges in database. These users/groups are virtual users (eg. user1 under the Role 'Manager') and they do not exist in LDAP server. We are integrating our application with FileNet for document management. For any document related operation, our application will inturn calls FileNet. Our challenge is that FileNet expects real user(present in LDAP) for authentication. We are not in a situation to create these users/ roles in LDAP as the list of users/ roles is huge and becomes an overhead. How to overcome this problem?
This topic has been locked.
2 replies Latest Post - 2013-01-17T00:45:32Z by cwoliveira
Pinned topic Configure FileNet to work with database for authentication instead of LDAP
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2013-01-17T00:45:32Z at 2013-01-17T00:45:32Z by cwoliveira
SystemAdmin 110000D4XK697 Posts
cwoliveira 270003P29725 PostsACCEPTED ANSWER
Re: Configure FileNet to work with database for authentication instead of LDAP2013-01-17T00:45:32Z in response to SystemAdminHi,
I agree with you, that's a challenge. FileNet security is designed with two major "sub-systems":
1 - Authentication: it's based on J2EE application server (ex: WAS) security. Here it's possible to enable SSO, custom user registry with external systems, federated repositories, security domains, etc.
2 - Authorization: it's based on communication from FileNet CE J2EE Application to a registered/supported Directory Server (LDAP)
So, FileNet still needs a Directory Server in order to perform objects authorization.
A workaround (STRONGLY NOT RECOMMENDED AND PROBABLY NOT SUPPORTED BY IBM) would be create on LDAP only one or more users for FileNet to work as "FileNet Service Users". Your application will log on FileNet with those accounts instead your end-users credentials. The major impacts of this approach will be the "FileNet Service Users" needing all possible permissions (ex: Obj Store Admin) required by application and all audit records on FileNet being saved for "FileNet Service Users".