Frontiers of Authentication and Authorization

Copyright 2003

Kenneth J. Klingenstein Internet2 and UC-Boulder

Camp Meeting, June 5th, 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 (www.realuser.com)

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 EducationFederation Space

REFCluster

InQueue(includes existing base)Only metadata

InCommon

SWITCH

The ShibResearch Club

Other national nets

Other clustersOther

potential USR+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• http://csrc.nist.gov/rbac/

• http://csrc.nist.gov/rbac/rbac-std-abs.html

• Recent HIPAA interest

William Winsborough work

A Tour of RBAC

The Enterprise Attribute River

Stanford University Authority Project

http://www.stanford.edu/group/itss-ccs/project/authority/

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