The current implementation doesn't use a standard way to define the security realm and access control. The realm uses a custom code that reads the access control list defined in acl.ldif and auth.properties.
<Realm className="com.netscape.cmscore.realm.PKIJNDIRealm" ... roleBase="ou=groups,ou=ca,dc=example,dc=com" roleName="cn" roleSubtree="true" roleSearch="(uniqueMember={0})" ... aclBase ="cn=aclResources,ou=ca,dc=example,dc=com" aclAttrName="resourceACLS" />
J2EE provides a more standard way to define access control using roles.
http://docs.oracle.com/javaee/6/tutorial/doc/bnbxj.html#bnbxk
Ideally the application should define a set of roles which contain users/groups. The roles are used to grant the users/groups access to certain resources in the application. The set of roles will be fixed in the application, but the user/group-to-role mapping will be stored in LDAP. This way the mapping can be dynamically managed without changing the application.
For example, the "Certificate Request Approver" role allows users/groups to approve/reject certificate requests. In web.xml the security constraint will be defined as follows:
<security-constraint> <web-resource-collection> ... <url-pattern>/pki/certrequest/approve</url-pattern> <url-pattern>/pki/certrequest/reject</url-pattern> ... </web-resource-collection> <auth-constraint> <role-name>Certificate Request Approver</role-name> </auth-constraint> ... </security-constraint>
In the LDAP server there will be separate subtrees for users, groups, and roles. There will be a corresponding LDAP entry for the "Certificate Request Approver" role above. The entry may have members such as "Certificate Manager Agents" group or "admin" user.
It should be possible now to use a standard JNDI realm which uses the roles instead of groups, assuming the LDAP server can resolve indirect membership.
<Realm className="org.apache.catalina.realm.JNDIRealm" ... roleBase="ou=roles,ou=ca,dc=example,dc=com" roleName="cn" roleSubtree="true" roleSearch="(uniqueMember={0})" />
Metadata Update from @edewata: - Issue assigned to jmagne - Issue set to the milestone: UNTRIAGED
Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.
This issue has been cloned to GitHub and is available here: https://github.com/dogtagpki/pki/issues/829
If you want to receive further updates on the issue, please navigate to the GitHub issue and click on Subscribe button.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.
Metadata Update from @dmoluguw: - Issue close_status updated to: migrated - Issue status updated to: Closed (was: Open)