Changes between Version 1 and Version 2 of ALL__security_edirrole


Ignore:
Timestamp:
11/25/14 14:56:17 (10 years ago)
Author:
lttoth@…
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ALL__security_edirrole

    v1 v2  
    88boxes under ~iplanet/local/ldap/scripts. 
    99 
     10== EDIRrole Overview == 
    1011EDIRrole is a locally defined attribute used to make attribute based authorization  
    1112decisions within EDIR, AUTHSERV, their UPDATE back end and at the directory   
     
    2122that reference them.   
    2223 
    23 There are currently 2900+ distinct EDIRrole values but most are flavors of the  
    24 following: 
    25  
    26         ADadmin         # the ability to administer AD related attributes 
    27         EDIRadmin       # the ability to administer any self service attribute 
    28         abideByFERPA    # the ability to see FERPA protected student records 
    29         deptAdmin<unitUIDpattern>       # the ability to update unit records 
    30         emailAdmin                      # the ability to administer email related attributes 
    31         emplAdmin<unitUIDpattern>       # the ability to update people records associated with unit 
    32         helpDesk                # the ability to perform restricted account management tasks 
    33         phoneBook               # the ability to administer phoneBook related attributes 
    34         secretaryAdmin          # the ability to administer the secretary attribute  
    35         sponsorAccount          # the ability to sponsor directory records (includes guest account creation) 
    36         tklAdmin<TKLpattern>    # the ability to update people records associated with TKL 
     24== EDIRrole General Groupings == 
     25There are currently 2900+ distinct EDIRrole values but most fall under the following general categories: 
     26        ||= **EDIRrole Identity** =||= **Permissions Granted** =|| 
     27        || ADadmin              || Administration of AD related attributes ||  
     28        || EDIRadmin    ||  Administration of  any self service attribute ||   
     29        || abideByFERPA || View FERPA protected student records ||   
     30        || deptAdmin<unitUIDpattern> ||  Update unit records ||   
     31        || emailAdmin           ||      Administration of  email related attributes ||   
     32        || emplAdmin<unitUIDpattern> ||  Update people records associated with unit ||   
     33        || helpDesk             ||  Perform restricted account management tasks ||   
     34        || phoneBook            ||  Administration of phoneBook related attributes ||  
     35        || secretaryAdmin       ||  Administration of  the secretary attribute ||  
     36        || sponsorAccount               ||  Sponsor directory records (includes guest account creation ) ||  
     37        || tklAdmin<TKLpattern> ||  Update    people records associated with TKL ||  
    3738 
    3839The greatest variety exists in the deptAdmin* emplAdmin* and tklAdmin* EDIRrole  
     
    4041units/TKLs which roll up to a common record. 
    4142 
     43== EDIRrole Provisioning == 
    4244EDIRrole values are provisioned on ou=people records by the ZUAUSR application when  
    4345it processes super classes that contain EDIR related grants.  Since ZUAUSR is an  
    4446application that supports provisioning of administrative access only to employee  
    4547accounts (and a handful of exceptions), EDIRrole values must be manually provisioned  
    46 by TSAA staff on ou=resource records and on any ou=people records not handled by  
    47 ZUAUSR. 
     48by OIT Technical Services Account Administration staff on ou=resource records and on any ou=people records not handled by ZUAUSR. 
    4849 
    49 The iPlanet roles based on EDIRrole values come in two flavors: those that apply to  
    50 people accessing other records and those that apply to resource accounts accessing  
    51 other records.  The iPlanet roles that govern people's access require that the person  
    52 doing the accessing have a current job assignment.  That helps insure that users  
     50== iPlanet Roles == 
     51The iPlanet roles based on EDIRrole values are divided into two categories:  
     52  * those that apply to people accessing other records 
     53  * those that apply to resource accounts accessing other records.   
     54 
     55The iPlanet roles that govern people's access require that the person  
     56requesting access have a current job assignment.  That helps insure that users  
    5357who leave the university do not retain viable directory access even if account  
    5458administration practices do not result in the timely revocation of administrative  
    55 accesses. 
     59accesses.  The following example shows the controls for permission to administer EDIR. 
    5660 
    57         iplanet@egegik> cat role.EDIRadminRole.ldif          
    58         dn: cn=EDIRadminRole,ou=people,dc=alaska,dc=edu 
    59         objectclass: top 
    60         objectclass: LDAPsubentry 
    61         objectclass: nsRoleDefinition 
    62         objectclass: nsComplexRoleDefinition 
    63         objectclass: nsFilteredRoleDefinition 
    64         cn: EDIRadminRole 
    65         nsRoleFilter: (&(EDIRROLE=*)(EDIRrole=EDIRadmin)(eduPersonAffiliation=Employee)(assignmentCount=*)(!(assignmentCount=0))) 
    66         Description: filtered role for entities administering EDIR 
    67          
     61{{{ 
     62$ iplanet@egegik> cat role.EDIRadminRole.ldif          
     63dn: cn=EDIRadminRole,ou=people,dc=alaska,dc=edu 
     64objectclass: top 
     65objectclass: LDAPsubentry 
     66objectclass: nsRoleDefinition 
     67objectclass: nsComplexRoleDefinition 
     68objectclass: nsFilteredRoleDefinition 
     69cn: EDIRadminRole 
     70nsRoleFilter: (&(EDIRROLE=*)(EDIRrole=EDIRadmin)(eduPersonAffiliation=Employee)(assignmentCount=*)(!(assignmentCount=0))) 
     71Description: filtered role for entities administering EDIR 
     72}}} 
    6873Resource credentials on the other hand are granted to applications not people and  
    6974applications do not have current job assignments so the assignment criteria is omitted: 
    7075 
    71         iplanet@egegik> cat role.EDIRadminRole.resource.ldif 
    72         dn: cn=EDIRadminRole,ou=resource,dc=alaska,dc=edu 
    73         objectclass: top 
    74         objectclass: LDAPsubentry 
    75         objectclass: nsRoleDefinition 
    76         objectclass: nsComplexRoleDefinition 
    77         objectclass: nsFilteredRoleDefinition 
    78         cn: EDIRadminRole 
    79         nsRoleFilter: (&(EDIRROLE=*)(EDIRrole=EDIRadmin)) 
    80         Description: filtered role for resource entities administering EDIR 
    81  
     76{{{ 
     77$ iplanet@egegik> cat role.EDIRadminRole.resource.ldif 
     78dn: cn=EDIRadminRole,ou=resource,dc=alaska,dc=edu 
     79objectclass: top 
     80objectclass: LDAPsubentry 
     81objectclass: nsRoleDefinition 
     82objectclass: nsComplexRoleDefinition 
     83objectclass: nsFilteredRoleDefinition 
     84cn: EDIRadminRole 
     85nsRoleFilter: (&(EDIRROLE=*)(EDIRrole=EDIRadmin))Description: filtered role for resource entities administering EDIR 
     86}}} 
    8287iPlanet roles are created and deleted as follows: 
    8388