Embed Size (px)
Citation preview
Centralized Application PermissionsPrivilege Management
Nate [email protected]
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?
