1 / 6

Groups in the Electronic Directory:

This solution allows for the provision of group memberships into our electronic directory, preserving group membership read access. No anonymous group names are available.

egonzalez
Download Presentation

Groups in the Electronic Directory:

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Groups in the Electronic Directory: • Requirements: • Provision group memberships into our electronic directory where they can be used by applications such as Oracle Calendar and our own CUWebAuth • Preserve Group Membership read access • No requirement to make the names of the groups anonymously available from the electronic directory

  2. Groups Directory dc = authz, dc = cornell, dc = edu objectclass = cornelledugroup attribute = cornellgroupreadpriv objectclass = edumember attribute = hasmember objec…. . ou = groups . . cn = cit.adsm.backline cornelledugroupreadpriv:backlineAppBindDN hasmember:se10@cornell.edu pb10@cornell.edu cn = cit.adsm cornelledugroupreadpriv:GrouperAll hasmember:jv11@cornell.edu jtp5@cornell.edu . . . . . .

  3. ACIs on Groups Directory • Allow read access to hasMember for anyone if cornelledugroupreadpriv=GrouperAll • Allow read access to hasMember for bindDNs which have authenticated to the directory and are also in the cornelledugroupreadpriv attribute for the group • Allow read and write access to hasMember for the bindDN of the Grouper LDAP Provisioning Connector • And other special cases…

  4. Example: Setting up a Group • User “jv11” creates a group called “cit.staff” with anonymous membership read turned off (Grouper UI) • She adds members to the group (Grouper UI) • She also gives the application ID called “myAppBindDN” membership read privileges (Grouper UI) • The LDAP Provisioning connector writes the group “cit.staff” to the groups directory, and populates hasMember • A future version of the LDAP Provisioning Connector (or a homemade script) populates the cornelledugroupreadpriv attribute for the cit.staff group in the directory

  5. Example: an application wants to read the “hasMember” attribute for a group called “cit.staff” • Application binds to the directory as cn=myAppBinddn, ou=serviceids, dc=authz, dc=cornell, dc=edu • Application asks for “hasMember” attribute of group “cit.staff” • Directory returns “hasMember” is returned IF Cornelledugroupreadpriv=GrouperAll for “cit.staff” (false) OR Cornelledugroupreadpriv=myAppBinddn for “cit.staff” (true)

  6. Kerberos Authentication? • Our applications use Kerberos authentication, not LDAP • With our SunONE directory, we can set up Kerberos5 authentication for the application DNs

More Related