Integration Technologies for Grouper & Signet Tom Barton, U Chicago Joy Veronneau, Cornell Gary Brown, U Bristol Lynn McRae, Stanford

Distributed Access Management CAMP 2 Workshop Orientation Agenda –Intro: What are Grouper & Signet? What are the chief technical integration tasks to implement them? –Examine each of these integration areas –Handout Level of detail: capabilities, not syntax of configuration files Try to complement, not overlap, program of the CAMP that follows

Distributed Access Management CAMP 3

4 Relative Roles of Signet & Grouper Grouper Signet RBAC model Users are placed into groups (aka “roles”) Privileges are assigned to groups Groups can be arranged into hierarchies to indirectly bestow privileges Grouper manages, well, groups Signet manages privileges Separates responsibilities for identification & entitlement

Distributed Access Management CAMP 5 Relative Roles of Grouper & Signet Grouper Binary info – you’re either in some list or not Identity- or affiliation-based access control or distribution Identification layer of an encompassing access management scheme Locally tweak or combine other groups Signet Structured, qualified info – limits, conditions, scope, … Oriented to individuals rather than roles Human judgment and chain of authority essential for access decisions Enable functional, not just technical, people to manage privileges Supports policy control closer to source of authority Audit requirements

Distributed Access Management CAMP 6 Glimpses of Grouper & Signet

Distributed Access Management CAMP 7

8 Subject API Objective: Enable integration of IdM-enhancing tools with existing IdM infrastructure How: Abstraction layer –Abstracts object schema & identifiers –Abstracts back-end storage technology What: A Subject is an object of any type managed by the IdM system –person, group, application

Distributed Access Management CAMP 9 Sources & Subjects Source – a database of subjects –Common back-end store –Common object schema Subject –subjectId, unique within a Source Subject attributes –Identifying – e.g. netId, employeeId, studentId –Descriptive – e.g. name, department, title Subject reference: (subjectId, sourceId) ( In v0.2.1 it’s (subjectId, sourceId, typeId) )

Distributed Access Management CAMP 10 Subject API Capabilities Select/search –Get a Subject by its subjectId –Get a Subject by specifying the value of an identifying attribute –Get a Set of Subjects matching a substring search of its attributes Present –Single attribute, Map of all attributes

Distributed Access Management CAMP 11

Distributed Access Management CAMP 12 Reference Source Adapters JDBC Source Adapter –Heart of configuration is SQL code that implements each search & selection method –Returns one table, each row is one Subject, columns are their attributes JNDI Source Adapter –Heart of configuration is an LDAP query specification implementing each search & selection method

Distributed Access Management CAMP 13 Design Issues For Subject API Deployment Choice of subjectId namespaces Consistency of sourceId assignment and subjectId namespace across multiple Source Adapter instances Subject v0.2.1 (current) vs. v1.0 –No more subject “types” –Enabling applications to behave differently with different “types” of subjects