Security and information assurance

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
 AuthenticationAuthentication
 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)
<SAMLQueryResponse>
<RequestID>urn:random:32q4schaw983y5982q35yh98q324==
<Assertion>
<AssertionID>http://www.bizexchange.test/assertion/AE0221
<Issuer>URN:dns-date:www.bizexchange.test:2001-01-03:19283
<ValidityInterval>
<NotBefore>
<NotOnOrAfter>
<Conditions>
<Audience>http://www.bizexchange.test/rule_book.html
<Claims>
<Subject>
<NameID>mailto:Alice@bizex.test
<Object>
<Authority>
<Permission>Read
<Resource>http://store.carol.test/finance
<Role>URN:dns-date:www.bizexchange.test:2001-01-04:right:finance

17. SAML Assertion (XACML embedded)
<TBS-POLICY-QueryResponse>
<RequestID>urn:random:zwos43i55098w4tawo3i5j09q==
<Assertion>
<AssertionID>http://policy.carol.test/assertion/
<Issuer>URN:dns-date:policy.carol.test:2001-03-03:1204
<ValidityInterval>
<NotBefore>
<NotOnOrAfter>
<Claim>
<Policy>
<Resources>
<string>http://store.carol.test/finance
<ACL>
<ACE>
<Subject>
<Role>URN:dns-date:www.bizexchange.test:2001-01-04:right:finance
<Permit>RWED
<ACE>
<Deny>ED
<Subject>
<Right>URN:dns-date:www.bizexchange.test:2001-01-04:right:ops
<Permit>R
<ACE>

18. Web Browser Password Access
nd Roles {
ncrypt {
}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
 <form> 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
AccessControl

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