1. Security and Information Assurance UC San Diego CSE 294 Winter Quarter 2008 Barry Demchak

2. Roadmap Challenges and Context Basic Web Authentication and Authorization SAML Signon sequence Shibboleth OpenID Compare and Contrast

3. Information Assurance Challenges Managing information-related risks [Wikipedia] How can we assure that information is being used in the way intended and by the people intended? Information: Which information? What quality of information? What are its characteristics? Way: Viewed? Changed? Reconveyed? Intended: By whom? With what degree of certainty? People: Browsers? Other user agents? Computer programs?

4. Information Assurance Problems (cont’d) Subproblems Security Policy Governance Data Quality Digital Rights Management … Parties User agents Data sources Data intermediaries Applications e-Commerce All commerce HIPAA SOX DOD

5. Consequence of Mishandling Information “Thousands of Brits fall victim to data theft” -- October 10, 2006 New York Times “Medicare and Medicaid Security Gaps Are Found” -- October 8, 2006 New York Times “U.S. and Europe Agree on Passenger Data” -- October 6, 2006 New York Times Is AJAX secure? -- October, 2006 SQL Magazine

6. An Immediate Challenge Securing a web site – 3 tier architecture Line-level protocols Trusted authorities Authentication Authentication Authorization Policy Governance Failure Detection/ Mitigation Process Separation Validation/Verification Privacy Correctness Safety Availability Integrity (Scalability) Privacy Correctness Safety Availability Integrity Eavesdropping Impersonation (MiM)

7. Authentication (Single Signon) Preserve Privacy Hint: Federations

8. Identity Federation Authenticated on one server  trusted on others Standards-based information exchange ( SSL, HTTP, SAML, … ) Result: portable identity

9. SSO Example – UCSD

10. Identity at UCSD

11. Basic Web Authentication/Authorization 1. User surfs to site and supplies credentials 2. Web site validates credentials and determines capabilities 3. Web site doles out resources per capabilities Separate authentication and authorization mechanisms from web site  loose coupling and separation of concerns Mechanism reuse Minimal impact on web site No impact on browser

12. Web Commerce Use Case Carol’s store is part of the Business Exchange (BusEx) Alice is signed up with the BusEx Alice wants to buy from Carol, and the BusEx provides authentication/authorization support

13. Web Browser Password Access Mission Convert Alice’s identity into capabilities Deliver resource from Carol to Alice Store identity on Alice’s PC as cookies for later Cast of Characters (roles) P = Principal CC = Credentials Collector AuA.v = Authentication Authority (verifier) AuA.a = Authentication Authority (assertions) PDP = Policy Decision Point PEP = Policy Enforcement Point

14. Security Attribute Markup Language XML framework for marshaling security and identity information Wraps existing security technologies (e.g., XACML) Describes assertions about subjects Bindings for SOAP, HTTP redirect, HTTP POST, HTTP artifact, URI Is not a crypto technology, assertion maintenance protocol, data format, etc.

15. SAML Assertion Example: Alice can read finance database

16. SAML Assertion (Query Response) urn:random:32q4schaw983y5982q35yh98q324== http://www.bizexchange.test/assertion/AE0221 URN:dns-date:www.bizexchange.test:2001-01-03:19283 http://www.bizexchange.test/rule_book.html mailto:Alice@bizex.test Read http://store.carol.test/finance URN:dns-date:www.bizexchange.test:2001-01-04:right:finance

17. SAML Assertion (XACML embedded) urn:random:zwos43i55098w4tawo3i5j09q== http://policy.carol.test/assertion/ URN:dns-date:policy.carol.test:2001-03-03:1204 http://store.carol.test/finance URN:dns-date:www.bizexchange.test:2001-01-04:right:finance RWED ED URN:dns-date:www.bizexchange.test:2001-01-04:right:ops R

18. Web Browser Password Access Bind Roles { Encrypt { } Establish Identity Enforce Policy {

19. Web Browser Password Access Choose an Identification Provider (IdP) Data Flow User Agent (UA) to IdP IdP to Service Provider (SP) – redirect through UA SP to IdP – verify credential based on ticket SP to UA – deliver resource Redirect method vs Post method HTTP 302 and Javascript

20. Decisions and Policy Store  Retrieve Policy  Retrieve Assertion  Compare Policy and Assertion  Render result of decision

21. Shibboleth Context

22. About Shibboleth Open source project sponsored by MACE (Middleware Architecture Committee for Education) of Interent2 Allows Single Signon and Identity Federations Enables policy-driven authorization Small integration effort for existing web applications Built on standards HTTP XML XML Schema XML Signature SOAP SAML (Security Assertion Markup Language)

23. Shibboleth Framework User Agents (UAs) Access SPs oblivious to Shib and SSO Shibboleth (Shib) Orchestrates access to identity providers (IPs) and attribute providers (APs) Provides SP with only attributes or identities needed to make decision Service Providers (SPs) Use and enforce their own authentication mechanisms Decide whether a user can access a resource

24. Shibboleth Workflow (POST method)

25. Shibboleth Application Policy Decision/ Enforcement Point Existing Kerberos, AD, etc Java on Tomcat/Apache C++ on Apache or IIS HTTP headers

26. Shibboleth Attribute Transfer SP configuration file identifies attributes to be retrieved from credential IdP configuration file identifies attributes to the provided in the credential IdP can identify SP through Shire address End result: least privileges is enforced

27. OpenID Federated SSO service Open and standards-based (HTTP, et al, but not SAML) Participants: Google, IBM, Microsoft, VeriSign, Yahoo!, AOL, Symantec, Sun, and many others As of February 2008: 250M openIDs, 10K Websites Objective: Prove that an end user controls an identifier (e.g., bdemchak.myopenid.com)  authentication

28. OpenID Workflow

29. OpenID Application Policy Decision/ Enforcement Point Attribute Parsing Access Control

30. OpenID Capabilities Personas associated with ID User-control of persona and attributes released to a particular web site Requires explicit web site programming

31. Shibboleth vs OpenID Shibboleth is academic; OpenID is commercial Shibboleth uses SAML; OpenID uses attribute list Shibboleth federation is more flexible Shibboleth attempts to ease application coding OpenID leverages validations in the cloud … this list is only the beginning …

32. Original Goals 1. User surfs to site and supplies credentials 2. Web site validates credentials and determines capabilities 3. Web site doles out resources per capabilities Separate authentication and authorization mechanisms from web site  loose coupling and separation of concerns Mechanism reuse Minimal impact on web site No impact on browser

33. References http://syswiki.ucsd.edu/index.php/Single_Sign-On http://www.openid.net http://shibboleth.internet2.net http://shibboleth.internet2.edu/docs/draft-mace-shibboleth- tech-overview-latest.pdf http://www.oasis-open.org http://www.oasis-open.org/committees/security/docs/draft- sstc-saml-reqs-00.doc http://www.oasis- open.org/committees/download.php/13525/sstc-saml-exec- overview-2.0-cd-01-2col.pdf http://www.oasis-open.org/committees/security/docs/draft- sstc-core-phill-07.doc