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

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

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?

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

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

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)

Authentication (Single Signon) Preserve Privacy Hint: Federations

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

SSO Example – UCSD

Identity at UCSD

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

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

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

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.

SAML Assertion Example: Alice can read finance database

SAML Assertion (Query Response) urn:random:32q4schaw983y5982q35yh98q324== URN:dns-date: Read URN:dns-date:

SAML Assertion (XACML embedded) urn:random:zwos43i55098w4tawo3i5j09q== URN:dns-date:policy.carol.test: : URN:dns-date: RWED ED URN:dns-date: R

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

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

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

Shibboleth Context

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)

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

Shibboleth Workflow (POST method)

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

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

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

OpenID Workflow

OpenID Application Policy Decision/ Enforcement Point Attribute Parsing Access Control

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

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 …

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

References tech-overview-latest.pdf sstc-saml-reqs-00.doc open.org/committees/download.php/13525/sstc-saml-exec- overview-2.0-cd-01-2col.pdf sstc-core-phill-07.doc