Frontiers of Authentication and Authorization Copyright 2003 Kenneth J. Klingenstein Internet2 and UC-Boulder Camp Meeting, June 5 th, 2003

Topics Authentication Local authn –Passfaces and other paradigm busters –Credential convertors Interrealm authn –Trust models –Federations Authorization A few basics Plumbing authz into legacy apps External authz services –Policy and rights languages –PDP –PEP –Fitting to apps

Origin Side Architecture

Local authentication Passfaces ( Smart cards and dumb people Local PKI – for internal use only

Credential Converters Build on work of KX.509 out of Michigan Service needs for short-term certs in Grids, H.323, web authn, etc. Several short term tasks add other acts of authentication as inputs easy to configure output cert profiles cope with cert placement issues Several long term tasks expose the CA function and generalize capabilities expose and automate the identifier mapping function add diagnostic capabilities

Interrealm Authentication PKI The problems without bridges, the problems with bridges CP Issues and the new Citizen and Commerce CP Federal e-authentication Initiative Federations Liberty Alliance – v1.1, v2.0, SecuritiesHub, PingID Federated Passport Shibboleth

Three Types of federation Internal federations are occurring among the many subsidiaries of large companies, especially for those companies with more dynamic aggregations. Private federations occur among enterprises, typically within a market sector, that want to facilitate a specific set of transactions and interactions. Public federations address more free-standing, long-term, general-purpose requirements, and need to be more open about rules of engagement. Public federations face significant scaling issues and may not be able to leverage contractual relationships that private federations can.

Federations and Classic PKI They are very similar Both imply trust models Federations are a enterprise-enterprise PKI Local authentication may well be end-entity certs Name-space control is a critical issue And they are very different End user authentication a local decision Flat set of relationships; little hierarchy Focus as much on privacy as security Web Services only right now: no other apps, no encryption We get to define…

The Research and Education Federation Space REF Cluster InQueue (includes existing base) Only metadata InCommon SWITCH The Shib Research Club Other national nets Other clusters Other potential US R+E feds State of Penn Fin Aid Assoc NSDL Slippery slope - Med Centers, etc

InCommon Activities Current Process applications for admission into origin list or for being a target Manage central WAYF and distribution of Club Shib feed (members and their keys) Member services – information, key revocation; no tech support Facilitate federated member trust understandings Longer term…

A possible path for InCommon In response to real business drivers and feasible technologies increase the strengths of (identification, authentication, directory integrity, auditing) In the fall… Class 1 trust – no prescriptions, self-audits Perhaps a year later Class 2 trust - in person or proxied id, encrypted authn, self-audit Sometime later Class 3 trust – very strong identification, token authn, secured dir, external audit Closely coupled to PKI but ultimately distinct

Process the last three months Breadth of interest in Shib leads to design team discussions Discussions in FOO Conversations in the halls of lots of meetings Most recently, discussions with European and Australian middleware folks Internal Internet2 planning of storefront, operations, naming

Overall Trust Fabric

Simpleton’s Authz Mt Authorization, from whose top one sees the unified field theory of authzanity

A Better View of Authzanity The Enterprise Attribute River, feeding the legacy apps that plumb to it, for their own internal authz processing The Oracle in the Mountains providing authz advice/decision (permit, deny, permit with constraints, etc.) to the simple masses The Swarms of Policy Decision Point The Policy Enforcement Points throughout the land, implementing decisions The Interrealm Attribute Requestor The Packaging Plants for digital rights execution, etc.

Caveats to travelers A land of policy, technology and human nature Static and run time controls Layers of abstraction and laws of complexity Issues of trust and privacy are closely entwined

Authz: a few basics Can user X perform operation Y on object Z? NIST Role-Based Access Controls Recent HIPAA interest William Winsborough work

A Tour of RBAC

The Enterprise Attribute River Stanford University Authority Project Key individuals: Lynn McRae, Sandy Senti, the lingering vapors of Bob Morgan and Jeff Hodges… Marshals resources from a broad set of registries (for people, groups, policies, roles, etc) and directories, with innovative use of groups, to produce atomic entitlements for entry into existing authorization systems Provides users with facile tools for viewing, managing and delegating authority Requires reasonable alignment of roles within institution.

Stanford Authz Model

Stanford Authz Goals Simplification of authority policy, management and interpretation. We should be able to summarize the full rights and privileges of an individual "at a glance" or let departmental administrators view and manage together all authority in their department or division. Consistent application of authority rules via infrastructure services and synchronization of administrative authority data across systems. Integration of authority data with enterprise reference data to provide extended services such as delegation and automatic revocation of authority based on status and affiliation changes. Role-based authority, that is, management of privileges based on job function and assignments rather than attached to individuals.

Deliverables The deliverables consist of a Web interface and program APIs to provide distributed management (to the departments, to external programs) of access rights and privileges, and delivery of authority information through the infrastructure as directory data and authority events.

Qualifiers Contexts Prerequisites Limits read-only no-self Context and prerequisites determine whether you have the authority at all. Limits are applied at the time authority is used in order to place boundaries on the scope of that authority

Layers of Aggregation Roles Functions Tasks Entitlements - These are the atomic units of authority control

Assignment of authority Authority can be managed by assigning Functions directly to individuals. As illustrated above, the system also supports role based authority -- the ability to describe a job role within your department then assign functions to that role in the Authority system. Any individual assigned to that role gets all the privileges of that role, and it privileges move automatically to any new person who is assigned the role. We anticipate role- based authority to be the most prevalent at the department level. The system should facilitate the management of such assignments by making it easy to identify individuals with roles and the privileges they have, easy to move people in and out of roles, easy to clone/duplicate/derive new roles, etc.

The 80/20 Rule of Functions A good set of basic functions should cover the majority of departmental requirements for managing authority. The system will allow some degree of direct control over enabling authority at the task level (either by direct assignment or by modifying tasks within a function). This is the way of addressing "the other 20%" of authority needs within an organization

External authorization service For what types of applications can the business logic be separated from the transaction processing? For what applications does this make sense? Videoconferencing Enterprise P2P DRM

Components of an external authz PDP Rights languages (on the users, relative to an operation) Policy languages (on objects, relative to an operation) Decision engine Type of value returned Tools to configure