Embed Size (px)
Citation preview
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. XACML-based)
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
faculty
staff
student
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 • names are consistent across institutions
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
