Internet 2 Shibboleth Project RL Bob Morgan University

Internet 2 Shibboleth Project RL "Bob" Morgan, University of Washington February 1, 2002

Topics How it came to be Scope and assumptions Architecture SAML Club Shib Status

How it came to be Around a dinner table in Tucson, Feb 2000. . . �Campuses have "local web sign-on" could we "hook them together"? Some principles: �Inter-institutional federation �No passwords where they don't belong. . . �Attribute-based authorization �Privacy protection Start with survey of campus web authn/z

Scope and assumptions Web-only (but the web infects all. . . ) Target scenarios �workgroup: named user accessing shared stuff �course: course/group member accessing. . . �site-licensed content: affiliation-based access to "digital library" resources Rely on "origin site" for user authn, user info PKI: for system components Yes, for end-user No (ie, not required)

Why we're not crazy (maybe) Inter-institutional infra is a pond with many dead guppies, but now we have: OASIS: SAML standards effort MS: Passport Liberty Alliance UK: Athens/Sparta, ES: Rediris/PAPI Project Meteor (Dept of Ed etc), NSDL, etc "verified by Visa"

Shibboleth Architecture Support user authentication via �redirection to "home" web authn page, via "where are you from" function �or, client certs direct to target Target establishes user context then fetches user attributes Origin site "Attribute authority" releases attributes, implements privacy controls Target resource manager decides on access

Shibboleth Architecture

The Shibboleth Onion SAML for core syntax, protocol �why not X. 509, why not LDAP? well. . . XML seems a good bet going forward Shib "profile" of SAML �add some missing pieces; define attribute schema; define cert/signature use; set some limits �and a software implementation of all this "Club Shib" �authn/attr practice statements; policy agreements; root CAs; service levels; etc

SAML in one slide Security Assertion Markup Language �specification from OASIS Security Services TC �supports interop among "web access management" products and deployments �supports "async" and B 2 B processes too �defines Assertions in XML for carrying Authentication, Attribute, Authz Decision statements �defines simple XML request/response protocol that runs over SOAP (or HTTP or other) �could be security format for other XML protocols

SAML players Netegrity, Securant (now RSA) contributed initial specs (S 2 ML, Auth. XML) Other major vendors/contributors: �Baltimore, Entrust, Entegrity, HP, IBM/Tivoli, Oblix, Sun, Veri. Sign, Jamcracker, others (and Internet 2!) Areas of expertise of participants: �"distributed systems security" (i. e. , DCE) �PKI �XML (SOAP, schema definition, web services)

SAML scope/structure XML-format Assertions as fundamental tech �used for core authn/authz purposes �exchange of security info between systems/domains �also extensible for other XML-based assertions �e. g. OASIS XACML (ACLs in XML, sort of) TC Protocol as simple means to get Assertions �runs over existing "transports" eg SOAP Profiles specify use in application scenarios �e. g. , web browser sign-on scenario

SAML Assertions Authentication �statement that Subject authenticated at time T �authentication exchange itself is not in SAML scope Attribute �statement that Subject has stated attributes �presumably but not necessarily "authorization" attrs Authorization Decision �statement that resource request is granted/denied

Assertion basics Each Assertion has: �Assertion ID (just a string) �Subject �optional Subject. Confirmation, e. g. public key �Name. Identifier = Name + Security. Domain �Issue. Instant �Issuer (just a string) �Conditions: critical (i. e. , "must process") elements �Advice: other non-critical items �Signing (via XMLDSIG) optional

Assertion example <saml: Assertion Major. Version=� 1� Minor. Version=� 0� Assertion. ID=� 140. 142. 167. 32. 12345678� Issuer=� hs. washington. edu� Issue. Instant=� 2002 -02 -02 T 02: 02 Z� > <saml: Conditions Not. Before=� 2002 -02 -02 T 02: 02 Z� Not. On. Or. After=� 2002 -02 -02 T 22: 00 Z� /> <saml: Authentication. Statement Authentication. Method=� password� Authentication. Instant=� 2002 -02 -02 T 02: 00 Z� > <saml: Subject> <saml: Name. Identifier Security. Domain=� washington. edu� Name=� a 39 dd 624 -aa 0 a-4786 -b 016 -230 f 8 b� /> </saml: Subject> </saml: Authentication. Statement>

Request/response protocol Simplest possible protocol for requesting/supplying any kind of assertion �not intended to rival SQL, LDAP, etc Authentication, Attribute Assertions are requested for a particular Subject Authz Decision Assertion request is: �is action Y on resource Z by subject S permitted? This protocol is not the only way to get Assns

Browser profile Supports the standard web sign-on case �user initial authentication not in scope, session management also left for later Size limits of URLs, cookies a problem �"Artifact" refers to an assertion, is small enough to travel in URL/cookie �used by receiver to request full (authn) assertion Or: use HTTP POST to send full assertion Both methods will be specified

SAML Status After a year of work. . . "Core" document mostly done (rev 25 now) �includes assertion and protocol schema Profile/bindings more or less done (rev 9) Conformance, sec/priv docs getting closer Shooting for "last call" Feb 5 Netegrity released open toolkit in October

Invidious comparisons SAML vs. X. 509? �X. 509 certs underlie authentication, SSL, DSIG �Authn Assns are somewhat like PK certs �Attr Assns are very much like X. 509 Attr certs �still disjunction between ASN. 1 and XML (really, ASN. 1 "schema" vs XML Schema) SAML vs Kerberos? �Authn Assn like session ticket �Kerberos fine as binding/transport, once specified �Kerberos per se has no authz data format

Shib AA vs LDAP Directory Shib attributes based on Edu. Person �not expressed in LDAP syntax but straightforward mapping, in most cases �possibility of complex XML-formatted attrs Shib AA can use your backend of choice �LDAP DS will be supported �also vanilla DBMS �could be entirely dynamic

Club Shib One possible aggregation of: �info-generation and -handling policies �PKI arrangements �rules of engagement �campuses, info/service providers, other "Club Boeing" a possibility. . . or will most arrangements be bilateral?

Shibboleth status Coding happening �cool three-headed process (OSU, CMU, IBM) �first public demo tomorrow! "Alpha" pilots engaged �content providers, academic services, user sites �but please come with your users and apps "Club" definition still in progress Evangelism happening, and happening �Liberty, libraries, finance, IMS, etc

Shib Issues Attribute management will be hardest part �engaged UI work from Info schools Targets have to re-think authorization �privacy protection doesn't help them �advanced authz expressions, eg contracts Personalization, portals add complexity. . . and many others