Privilege and Access Management Jan Tax Identity Management Specialist UNC Chapel Hill
The Big Picture
Overview of Presentation Start with the basics of access management definitions stages and evolution Go over the use of user attributes, group memberships and entitlements to govern access to applications. Finish with an example of a recent request from an application developer that illustrates some of the techniques. Thanks to the Internet2 MACE-paccman Working Group for much of material used in this presentation https://spaces.internet2.edu/display/macepaccman/home
What is Access Management? Access Management is the set of policy-based and technology-based practices for controlling access to resources Definitions, for the purposes of this presentation: o Subject is a person or a service acting a person's behalf o Resource is a part of a system which needs to be protected by authorization o Group is a collection of Subjects o Privilege is an action that a Subject can perform on a Resource o Role is a collection of privileges Access management can get very complicated Categorizing Access Management Use Cases(Rob Carter and Scott Fullerton, June 2009 CAMP in Philadelphia) Let's look at the progression...
Stages of Access Management 1. Authentication only -- if you can login, you get everything 2. A user agreement saying you won't abuse the information you see (e.g. sysadmins) 3. Access control lists/tables (subject, privilege) hard-coded within each application 4. Access control lists/tables (subject, privilege) hard-coded within each application, combined with user attributes from central LDAP/ WS/DB/SSO 5. Access control lists managed outside the application by a central system (e.g. Grouper) and provided to the application 6. A rule-based, centralized service that can be consulted by applications to make grant or deny access decisions (e.g. XACMLbased) Most applications are in stages 3-5.
Stages of Access Management Access management is still in the early stages of maturity access is managed mostly at the application level movement toward centralizing/externalizing access management using directories (LDAP/AD) and group management systems (Grouper) centralization simplifies data management and can ease revocation of privileges -- do it in one place instead of in each application provisioning access is an alternative for applications that can't make direct use of the central identity and access management systems
Evolution of Access Management Access management is an ongoing process Start by using a single attribute -- affiliation -- and let applications use it to make access decisions. The eduperson LDAP schema defines a standard set of values for affiliation: member employee student faculty staff alum Add centrally-managed user attributes, group memberships derived from data provided by "systems of record" o student, employee type o departmental affiliations o course enrollments Allow application owners to manage their own groups
Groups Groups can be managed directly in LDAP or AD, or by a group management system such as Grouper. UNC Chapel Hill uses Grouper to manage: dynamic groups calculated from System of Record data cn: unc:org:3103:staff cn: unc:org:3103:employee cn: unc:org:3103:member application-specific groups managed with Grouper application cn: unc:app:its:grouper:admin cn: unc:app:its:grouper:users Groups are published to a separate groups container in LDAP. Group memberships can be provided by Shibboleth when a user authenticates for an agreed-upon set of groups.
Example: Group memberships UNC's content management system (CCM) uses group memberships retrieved from LDAP to control the type of access (rwda) to a document path. cn: unc:3103:comm:ccm:account:r:priv/its/comm/int/stationery cn: unc:3103:comm:ccm:account:r:priv/its/comm/int/media cn: unc:3103:comm:ccm:account:r:priv/km/its_resnet/student cn: unc:3103:comm:ccm:account:r:priv/its/ec cn: unc:3103:comm:ccm:account:rw:priv/km/its_idm cn: unc:3103:comm:ccm:account:rw:km/its_idm cn: unc:3103:comm:ccm:account:rwd:its/eapps/idm cn: unc:3103:comm:ccm:account:rwd:its/support/idm Grouper is used to manage the group structure and updates the LDAP directory when changes are made.
Entitlements Entitlements are an alternative to groups, useful in federated applications dealing with multiple identity providers Groups tend to put access control logic in the application application must have knowledge about meaning of group names names are not consistent across institutions Entitlements tend to put access control logic in the central system (attribute authority) can be calculated from group memberships
Example: Library Entitlement College and University Libraries contract for access to content from electronic resource providers Proxy servers (e.g. EZProxy) are used to allow access to the electronic resource providers from on-campus IP addresses From off-campus, either VPN to campus or... Shibboleth authentication + entitlement allows access from on- or off-campus edupersonentitlement: urn:mace:dir:entitlement:common-lib-terms Library resource providers have agreed to honor this entitlement, which is defined on each campus to include people covered by license terms.
Example: Grad School Apps Access Applications running in an application server needed to be access controlled Shibboleth is used for authentication and attribute retrieval in this case, but the mechanism could be LDAP/AD or something else Combinations of user attributes, group memberships, local table/list are used to govern access for each application
Application Restrict to Attributes Required Values Allow Deny Fellowships Database Graduate School Staff ismemberof unc:org:3901:staff Graduate School staff Other departments staff Any students Footprints Admin Graduate School Staff Enumerated by userid List of allowed userids Users whose userids are listed Any other users VPHD Graduate students uncstudenttype GRAD ABD GRAD DDG GRAD FX GRAD GD GRAD GM GRAD II GRAD MDP GRAD SPG GRAD Any graduate students in any department or program Any non-graduate students Funding Handbook Faculty/Staff (not students) employeetype EPA Faculty EPA Non-Faculty SPA Permanent faculty or staff from any department Students Student-employees of any department Temporary employees of any department
Questions/Comments? Jan Tax UNC Chapel Hill tax@unc.edu