tuomas aura t-110.4206 information security technology identity management aalto university, autumn...
TRANSCRIPT
Tuomas AuraT-110.4206 Information security technology
Identity management
Aalto University, autumn 2011
2
Outline1. Single sign-on2. OpenId3. SAML and Shibboleth4. Corporate IAM5. Strong identity
Single sign-on (SSO) Users have too many user accounts
– Cannot remember the passwords– Service access slow and inconvenient– Forgotten, unmanaged accounts are a security risk
Need for an SSO solution Pseudo-SSO: separate authentication to each service; client
software manages the credentials and hides the login from user Proxy-based SSO: proxy in network manages user credentials
and hides the login details from the client True SSO: user authenticates to a separate authentication
service, which asserts user identity to other services Federated SSO: authentication between administrative domains Main problem with SSO systems: there’re so many of them
3
OPENID
4
OpenId architecture
Standard for SSO to web sites– http://openid.net/developers/specs/
End user creates an OpenId (=identity) at some OpenId provider (OP) End user registers the OpenId at various relaying parties (RP) i.e. web sites End user authenticates to RP with the help of OP The end user needs a web browser i.e. user agent (UA)
5
Identity provider OPRelying party RP
Register OpenId for user account
End user / user agent UA
Authenticate
Create OpenId
OpenId 2.0 protocol
Identifier is an HTTP URL (or XRI): gives the OP address– e.g. username.myopenid.com, https://me.yahoo.com/username
Direct messages use HTTP POST Indirect messages use HTTP redirect
– Data fields sent as URL parameters via the browser Method of user authentication not specified; typically a password
6
Identity provider OPRelying party RP
1. Identifier
[3. Association: DH]
End user / user agent UA
8. Service access[7. Direct verification]
5. User authentication: e.g. password
6. Redirect: authentication approved/failed
4. Redirect: authentication request
2. OP discovery
(only if no step 3)
OpenId 2.0 security
Approval /failure message from OP to RP is authenticated with a timestamp and MAC– RP can establish a MAC key with Diffie-Hellman, or ask OP to verify the MAC for it
TLS not required by OpenId spec but needed for real security:– RP must authenticate OP in the Diffie-Hellman or direct verification step– UA must authenticate OP before user types in the password– TLS can be used between UA and RP to protect service access (Q: does it matter?)
User must pay attention:– Check HTTPS and OP name in the browser address bar before typing in the password– Check RP name presented by OP to approve login 7
2. OP discovery
Identity provider OPRelying party RP
1. Identifier
[3. Association: DH]
End user / user agent UA
8. Service access[7. Direct verifivation]
5. User authentication: e.g. password
6. Redirect: authentication approved/failed
4. Redirect: authentication request
TLS to authenticate the DH key exchange
TLS to protect the password
MAC with the association key
TLS to authenticate result
(only if no step 3)
User must check OP name and RP name
OpenId notes What does “open” mean?
– Anyone can become an identity provider– User can choose any identity provider– Services accept the identity chosen by the user– Works on any web browser without proprietary software
In practice, not always so open:– RP policy may determine which OPs are accepted– OP policy may determine which RPs are accepted
User-provided id may just point to OP without identifying the user– e.g. https://www.google.com/accounts/o8/id
OpenId specification is poorly written– Assumes the reader knows previous versions– Uses XRI, Yadis and XRDS: very complex and incomplete specifications
Security not obvious: – Focus on web technology, not on secure protocol design– Vague security claims especially when used without TLS
8
SAML AND SHIBBOLETH
9
SAML 2.0 architecture
Security assertion markup language (SAML 2.0)– OASIS standard (combines ideas from SAML 1.1, Liberty Alliance identity-
federation framework 1.2, and Shibboleth 1.3) Service provider (SP) and identity provider (IdP) establish a trust relation
by exchanging metadata Principal (= user, subject) registers with the IdP Principal authenticates to IdP and SP
10
Service provider SP
Trust relation
Principal
Register user
Identity provider IdP
Authenticate
SAML SAML is a complex family of protocols:
– Assertions are statements by IdP about a principal, written in XML– Protocols define message flows for requesting assertions– Bindings define how protocol messages are transported over
HTTP, SOAP etc.– Profiles define useful combinations of assertions, protocols and
bindings– Metadata defines trust relations
Unlike OpenId, SAML is based on contractual relations– Metadata must be exchanged between IdP and SP– Federation may set rules for its member IdPs and SPs– User cannot decide which id to use where
Typical profile: SAML web browser SSO profile
11
SAML web browser SSO profile IdP-initiated or SP-initiated SSO:
– User first logs into the IdP, or first connects to SP Bindings to HTTP messages
– Redirect: message from SP to IdP is sent in GET URL via browser, with help of HTTP redirection
– POST: message between SP and IdP is sent in HTTP form via browser, with the help of user or script
– Artifact: reference to message is sent in GET URL via browser, with the help of HTTP redirection, and the actual message is retrieved directly from sender
Other profiles support SOAP bindings12
SAML web browser SSO profile
Protocol for SP-initiated SSP:– AuthnRequest and Response
How to send these messages over HTTP? Need to choose bindings; 6 different combinations
13
Service provider SPPrincipal Identity provider IdP
1. Access request
Resource access
3. User login to IdP
2. <AuthnRequest>
4. <Response>
SP-initiated SSO
SAML web browser SSO profile
Example: redirect-artifact binding: – SP sends <AuthnRequest> to IdP in GET URL with HTTP redirect– IdP sends an artifact to SP in GET URL with HTTP redirect– SP retrieves <Response> from IdP with artifact resolution protocol
14
Service provider SPPrincipal Identity provider IdP
1. Access request
7. Resource access
3. User login to IdP
4. Redirect with artifact
2. Redirect: <AuthnRequest>
6. Artifact response (<Response>)
SAML Redirect-Artifact binding
SP-initiated SSO
5. Resolve artifact
SAML security
Response must be signed by IdP TSL needed for all connections:
– Protects password; protects secrecy of attributes; prevents redirection to wrong site
Attributes in Response signed by IdP 15
Service provider SPPrincipal Identity provider IdP
1. Access request
7. Resource access
3. User login to IdP
4. Redirect with artifact
2. Redirect: <AuthnRequest>
6. Artifact response 5. Resolve artifact
Sign with IdP signature key<Response>
TLS for all connections
Shibboleth 2 Open-source implementation of SAML 2.0 for web SSO (wiki)
– Developed by the Internet 2 project Used mainly in research and educational institutions; many other commercial
and open-source SAML implementation exist If SP supports multiple IdPs, SP-initiated authentication goes via the where are
you from (WAYF) page– One more step of redirection for the AuthnRequest
Two kinds of sessions: – IdP session with the IdP (cookies from IdP)– SP session with each SP (cookies from SP)
user only needs to type in password once; not single logout Federation is a group of IdPs and SPs that
– share metadata in one signed file– agree on an attribute schema– agree on CA for TLS– have a service agreement that sets out rules for the federation
e.g. Haka federation16
SAML attributes In addition to user identity, <Response> from IdP to SP
contains user attributes – Attributes sent to each SP are selected based on attribute
filters in metadata Example:
cn = Tuomas Aurao = Teknillinen korkeakoulueduPersonAffiliation = employee;faculty;member
Try https://talli.funet.fi/haka/attribute-test/ User attributes are personal data
For legal reasons, IdP needs user confirmation before transferring attributes to SP the annoying check box after IdP login
17
CORPORATE IAM
18
Corporate IAM Federated identity and authentication is not sufficient:
– Need to configure access permissions for users in the services– Need to monitor access control state in the system– Need to revoke access rights
Identity and access management (IAM) systems– Define roles and groups for the organization – Enable centralized role assignment, revocation and monitoring
Example:– student enrolls to university, then becomes employee, then
graduates, finally leaves employment Central IAM server and IAM agent at each supported service
more expensive to develop and deploy than federated authentication
19
20[Internet 2 Middleware Initiative]
STRONG IDENTITY
21
Strong authentication Goal: authentication equivalent to verifying national identity
card or passport Why is it needed?
– Initial id check when registering new users, e.g. students enrolling to university
– Required by law for access to government services and personal information
– Increasing trust in commercial online transactions — but this has already been solved in other ways
Why not use OpenId or SAML?– OpenId allows user to choose identifier no link to real person– SAML works internally in organizations and between organizations
that have a contract not for new or ad-hoc relations
22
Finnish electronic identity card Finnish identity cards (HST-kortti) have a
smartcard chip with three key pairs– Signature, encryption and authentication keys– http://www.fineid.fi/
Keys are certified by the national population register (VRK)
Has not gained popularity; few people have an id card; even fewer ever use it for electronic authentication– Why?
23
Tupas authentication Tupas uses bank accounts for strong
authentication– Defined by Federation of Finnish Financial Services
http://www.fkl.fi/teemasivut/sahkoinen_asiointi/tupas/
– Developed from online the payment system (commonly used in Finland for online purchases)
– User authentication with one-time passwords Advantage: everyone has a bank account, and
banks are required to know the identity of their customers no cost for identity proofing
Example: https://password.aalto.fi/ 24
Tupas authentication
Three-corner authentication model: user, user’s bank, online service Each service must set up a shared key with each bankSmaller banks are not supported by all online services
25
Online serviceUser Bank
1. Bank selection
5. Service access
3. One-time password login to bank
4. POST redirection: name, national id number, MAC
2. POST redirection
Authenticated with a shared key;id number may be encrypted
name, national id number, MAC
TLS for all connections
Mobile signature Mobile phone operators install a signature key on the SIM
– ETSI standard– Developed from earlier “business SIM”– No direct access from phone to signature key; signatures are
requested via the operator’s mobile signature service provider (MSSP) Advantages: everyone has a SIM card, and operators have 24/7
service for revocation Four-corner authentication model:
– Mobile operators have contracts with each other– Each service and user only needs to have a contract with one operator
Deployment and adoption has been slow– Heavy requirements for identity proofing– Operators want a fee for every transaction low number of
transactions no business model
26
Reading material Online:
– OpenId 2.0, http://openid.net/developers/specs/ – SAML 2.0 Technical Overview,
http://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf
27
Exercises How much security does OpenId exactly give if TLS is not used? Learn about XRI name space and XRI discovery. If XRI is used as the user
identifier in OpenId, how is the user supposed to authenticate the OP before typing in the password?
What is the difference to security and privacy if the user-provided id points to the OP without identifying the user, and the user identity is entered only at the OP site?
Look at the Haka federation metadata for Shibboleth 2. How does this create trust between an IdP and SP? What ways are there to limit the trust?
Can you capture the AuthnRequest and Response messages when logging into Noppa? Which bindings are used?
Why exactly is TLS needed at each stage in SAML/Shibboleth authentication, or is it?
Despite similarities in the protocols, OpenId, SAML and Tupas have different goals and make different assumptions about the relations between entities. What differences are there?
28