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