1 / 22

Internet2 Shibboleth Project

Internet2 Shibboleth Project. RL "Bob" Morgan, University of Washington. 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"?

leoma
Download Presentation

Internet2 Shibboleth Project

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Internet2 Shibboleth Project RL "Bob" Morgan, University of Washington

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

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

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

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

  6. 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 contextthen fetches user attributes Origin site "Attribute authority" releases attributes, implements privacy controls Target resource manager decides on access

  7. Shibboleth Architecture

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

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

  10. SAML players Netegrity, Securant (now RSA) contributed initial specs (S2ML, AuthXML) Other major vendors/contributors: • Baltimore, Entrust, Entegrity, HP, IBM/Tivoli, Oblix, Sun, VeriSign, Jamcracker, others (and Internet2!) Areas of expertise of participants: • "distributed systems security" (i.e., DCE) • PKI • XML (SOAP, schema definition, web services)

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

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

  13. Assertion basics Each Assertion has: • Assertion ID (just a string) • Subject • optional SubjectConfirmation, e.g. public key • NameIdentifier = Name + SecurityDomain • IssueInstant • Issuer (just a string) • Conditions: critical (i.e., "must process") elements • Advice: other non-critical items • Signing (via XMLDSIG) optional

  14. Assertion example • <saml:Assertion MajorVersion=“1” MinorVersion=“0” AssertionID=“140.142.167.32.12345678” Issuer=“hs.washington.edu“ IssueInstant=“2002-02-02T02:02:02Z”> <saml:Conditions NotBefore=“2002-02-02T02:02:02Z” NotOnOrAfter=“2002-02-02T22:02:00Z” /> <saml:AuthenticationStatement AuthenticationMethod=“password” AuthenticationInstant=“2002-02-02T02:02:00Z”> <saml:Subject> <saml:NameIdentifier SecurityDomain=“washington.edu” Name=“a39dd624-aa0a-4786-b016-230f8b” /> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion>

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

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

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

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

  19. Shib AA vs LDAP Directory Shib attributes based on EduPerson • 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

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

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

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

More Related