190 likes | 326 Views
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
E N D
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:attribute-def:eduPersonScopedAffiliation" AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace: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, Member@testshib.org 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 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?