Integration Technologies for Grouper & Signet

Tom Barton, U ChicagoJoy Veronneau, CornellGary Brown, U BristolLynn 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

Distributed Access Management CAMP

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

Distributed Access Management CAMP

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