Centralized Application Permissions

1. Centralized Application Permissions Privilege Management Nate Klingenstein ndk@internet2.edu 30 January 2007 OGF 19 Chapel Hill

2. 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)

3. 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

4. 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

5. 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

6. 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?

7. 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.

8. Privileges vs. Attributes vs. Groups • Redundancy and security requirements • Transport protocols, profiles, bindings, formats • How much can you squeeze into SAML? • XACML transport

9. What does a “Privilege” Look Like? • XACML • Signet • eduPersonEntitlement • URL & value

10. 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?

11. Introducing Signet • Centralized privilege management system • Supports privilege: • Issuance • Reissuance • Prohibition of reissuance • Delegation • Prohibition of Delegation • More information forthcoming…

12. 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?

13. 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?

14. 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?

15. Any Questions? Nate Klingenstein ndk@internet2.edu