Managing Roles & Privileges with
Grouper and Signet Middleware
Helsinki EuroCAMP, April 18, 2007
Nate Klingenstein
(some words stolen from Tom Barton & Lynn Mcrae)
Overview
• It’s all about data structures
– Attributes
– Groups
– Privileges
– And other more exotic forms
• It’s all about data management
– Databases, directories, people systems, and
more
– Signet manages complex permissions
– Grouper manages complex groups
What’s an Attribute?
• Intuitively easy to answer
– At least one name
• Sometimes more…
– At least one value
• Sometimes more…
– May be more structured
• Practically anything can be stuffed into an
attribute, whether string or structure
– Is this the right expression?
– All parties need to understand it
• The data surrounding an attribute are as
important as the attribute itself
What’s a Group?
• Intuitively easy to answer
– A set of people
• Usually with common characteristics
• Representing groups is also understood
– “Static” groups
• A group object represents the group and contains
membership and other information
– “Dynamic” groups
• If you have the secret attribute, you’re part of the
group
– One group can be represented both
ways
What’s a Permission?
• Intuitively easy to answer
– The right to perform some action on some
resource
• Usually within a context
• Representing permissions is somewhat
less understood
• Attribute-based access control hasn’t really
taken off
XACML
• A rule consists of a triplet: subject, resource,
action
• A policy is a set of rules and combinatorics
• Can be crammed into a SAML attribute or
requested through its own protocol
• Version 2.0 ratified in March 2005
• No interoperability event has been attempted
• Hasn’t been extremely popular
The Scope Experience
• <Attribute AttributeName="urn:mace:dir:attributedef:eduPersonScopedAffiliation"
AttributeNamespace="urn:mace:shibboleth:1.0:attributeNam
espace:uri">
<AttributeValue
Scope="testshib.org">Member</AttributeValue>
</Attribute>
• Oops
– Made interoperability with other systems much harder
– No applications wanted to deal with this much structure
• Much less XML
• In retrospect, [email protected] preferable
Sometimes it’s simple
• If a group can be represented as an
attribute carried by a set of users…
• If a privilege can be represented as an
attribute carried by a set of users…
• Thus, eduPersonEntitlement was born
But, sometimes it’s complex
• Overloading a string with too much
information is worse
– Whether or not a string is opaque can be a
religious battle
• Some systems make good use of complex
data structures
The chaos inside
• Think LDAP or relational database vs. data
delivered to applications
– They don’t want the user object or a database
dump
– But the DIT and triggers are extremely useful
• Manage your complex groups with Grouper
• Manage your permissions with Signet
– Export them to LDAP, a RDBMS, Shibboleth,
or other systems in your format of choice
Grouper
• Defines a “Groups Registry”
– Centralized management of groups
– Group math, group nesting, exclusion criteria
– Hierarchical name-space (name stems &
substems)
– When you’re done, export the group to the
systems that use or store it
• Can feed from existing group information
• Supports the creation of new groups
– By schools, departments, and individuals!
– Distributed/delegated model of control
Signet
• Brings privilege information together in one
place -- a “Privilege Registry”
– Central granting, can apply across
multiple systems
– Central reporting, history, auditing,
review
– Accessible to managers and holders of
privileges
• Independent of specific vendors, systems,
releases or technologies
• Distributed/delegated model of control
Enough talk
• Example time -- and this time you can help
• http://signet-demo.stanford.edu
• Super-user: demo/signet
• Other users: username/signet
– tbarton/signet
– lmcrae/signet
Privilege Elements by Example
By authority of the Dean
grantor
principal investigators
grantee (group/role)
who have completed training
prerequisite
can approve purchases
function
in the School of Medicine
scope
for research projects
resource
up to $100,000
limit
until January 1, 2007
as long as a faculty member at…
conditions
Privilege
Lifecycle
Configuring Signet
• XML configuration files:
– subsystem.xml
• Defines the set of permissions, limits, etc. that exist
– tree.xml
• Defines the structure of trees and scopes
– users.xml
• Creates user data if you don’t have it already
• Database of your choice provides the real
backend
– SQL scripts to create Signet tables are
provided for most major databases
Configuring Grouper
• Mix of manual and automation processes
manage a common Groups Registry
– Stored in an RDBMS
– Information provisioned from here to
enterprise data stores
• Opt-in and opt-out supported
– People can, subject to policy, change their
own memberships
Composite Groups
• Composite group membership is computed
dynamically
– A = B U C union
– A = B ∩ C intersection
– A = B – C relative complement
• Common use – “tweak” existing groups
– Whitelist or blacklist factored in to another
group
Exporting from Grouper
• API
• XML Import/Export Tool
– Snapshots Groups Registry, including naming
stems and privileges
•
•
•
•
A single group
All subordinate to a specified naming stem
All matching a search condition
Entire Registry
• LDAP Provisioning Connector
Federating Permissions & Groups
• The really big question: how do you knit
together groups and permissions across
realms?
– Is it sufficient to just assert common attribute
values?
– Use common privilege definition metadata?
– Integrate systems at a deeper layer than just
attribute & metadata exchange?
• Does the virtual organization (VO) / IdP
proxy model address this problem?