Centralized Application Permissions Privilege Management Nate Klingenstein ndk@internet2.edu 30...

Centralized Application PermissionsPrivilege Management

Nate Klingensteinndk@internet2.edu

30 January 2007

OGF 19 Chapel Hill

The Saga

• Getting applications to relinquish authentication is pretty hard

• Getting applications to relinquish attribute control is harder

• Getting applications to relinquish control of authorizations…

(fine print: do so in an inter-realm context too)

The Applications Have a Point

• Identity-based functions often live deep inside the application– How can you better identify and handle my

authorization needs than me?– Why do I have to consult you when my

application makes a decision?– Why do I need to work with you every time I

want to change my permission definitions?

• Application databases and directories have worked great for years

The IT Guys Also Have a Point

• There’s tremendous duplication of effort

• Distributed information is more likely to be compromised

• Users can barely take care of one set of information, privileges, or credentials

• This is all we’ve got to live for– So we do it well

• Auditors exist, and also do it well– Compliance

Privilege Centralization Considerations

• Broader applicability– Granularity again

• How precise is your privilege definition?• How many other source and destination

systems could share your definition?

• The same questions apply when deciding whether to federate privileges– Intra-realm SSO & centralization is a subset of

federated identity; the same tools should handle both

Privileges vs. Attributes vs. Groups

• We can instinctually determine what the difference is

• In digital systems, the distinction is less clear

• Is the difference only semantic?– Formats?

– Management?

• How do these structures in source systems line up with those in apps?

Privileges Based on Attributes

• We’re all familiar with privileges based on attributes– VOMS– Standard Shibboleth

• How do permissions based on attributes differ from individual privileges?– Grouping of permissions– Granularity

• RBAC models– MIT– NIST– Stanford– Etc.

Privileges vs. Attributes vs. Groups

• Redundancy and security requirements• Transport protocols, profiles, bindings, formats

– How much can you squeeze into SAML?– XACML transport

What does a “Privilege” Look Like?

• XACML

• Signet

• eduPersonEntitlement

• URL & value

Privileges for Applications

• What do you deliver to an application?

• Is a boolean good enough?

• If not, what do you consume?

• What can your authorization system provide?– What can your partners provide?

Introducing Signet

• Centralized privilege management system• Supports privilege:

– Issuance– Reissuance– Prohibition of reissuance– Delegation– Prohibition of Delegation

• More information forthcoming…

Integrating Privilege Systems with Applications

• What data format do applications want?– Conditions– Variables

• Push, or pull?– Protocols

• When?– Freshness vs. Frustration– Caching?

• How do you define the appropriate central data structures?

Grid Permissions

• Are there sufficiently common privilege requirements across grids that we can:– Pick a format for consumers?– Define a vocabulary and naming style?– Build one or more templates?– Standardize a basic set?

• How is this expressed in a form the grid can use?– VOMS Attributes?

Integrating Signet with Signets

Dr. Jean Blue is a professor at Sandstone University and a PI of VORTEX, a virtual organization. As a PI of VORTEX, she has many VORTEX privileges and wants to administer them consistently across a variety of environments. She wants to assign her students permission to read one of the VORTEX mass-hypometers; etc.

• At what level do you connect the systems?• With what data harmonization?• Which transport mechanisms?

– Which transport formats?

• How do they synchronize? Authorize?

Any Questions?

Nate Klingenstein

ndk@internet2.edu