Identity management
Tuomas Aura
T-110.4206 Information security technology
Aalto University, autumn 2012
Outline
1.
2.
3.
4.
5.
Single sign-on
OpenId
SAML and Shibboleth
Corporate IAM
Strong identity
2
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
 SSO types:
– Pseudo-SSO: separate authentication to each service; client
software manages the credentials and hides the login from user
– Proxy-based SSO: pseudo-SSO implemented in a proxy; proxy in
the 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
End user / user agent UA
Relying party RP
Identity provider OP
Create OpenId
Register OpenId for
user account
Authenticate
 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
OpenId 2.0 protocol
End user / user agent UA
Relying party RP
Identity provider OP
1. Identifier
2. OP discovery
[3. Association: DH]
4. Redirect: authentication request
5. User authentication: e.g. password
6. Redirect: authentication approved/failed
[7. Direct verification]
(only if no step 3)
8. Service access

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 GET and Redirect
– Data fields sent as URL parameters via the browser

Method of user authentication not specified; typically a password
6
OpenId 2.0 security
End user / user agent UA
Relying party RP
Identity provider OP
1. Identifier
2. OP discovery
[3. Association: DH]
TLS to authenticate
the DH key exchange
4. Redirect: authentication request
User must check OP
name and RP name
TLS to protect
the password
5. User authentication: e.g. password
6. Redirect: authentication approved/failed
MAC with the association key
[7. Direct verifivation]
8. Service access

Approval /failure message from OP to RP is authenticated with a MAC and timestamp
–

RP can either establish a MAC key with Diffie-Hellman (step 3) or ask OP to verify the MAC for it (step 7)
TLS is not required by OpenId spec but needed for real security:
–
–
–

(only if no step 3)
TLS to
authenticate result
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 the OP name in the browser address bar before typing in the password
Check RP name on OP login page before approving login
7
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
 For privacy, 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 implementation, not on secure protocol design
– Vague security claims especially when used without TLS
8
SAML AND SHIBBOLETH
9
SAML 2.0 architecture
Principal
Service provider SP
Identity provider IdP
Trust relation
Register user
Authenticate
 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 then to SP
10
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 first 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, submitted by user click 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
 SOAP binding not used in this profile
12
SAML web browser SSO profile
Principal
Service provider SP
Identity provider IdP
SP-initiated
SSO
1. Access request
2. <AuthnRequest>
3. User login to IdP
4. <Response>
Resource access
 Protocol for SP-initiated SSP:
– AuthnRequest and Response
 How to send these messages over HTTP?
 Need to choose bindings; 6 different combinations
13
SAML web browser SSO profile
Principal
Service provider SP
Identity provider IdP
SP-initiated
SSO
1. Access request
2. Redirect: <AuthnRequest>
3. User login to IdP
SAML RedirectArtifact binding
4. Redirect with artifact
7. Resource access
5. Resolve artifact
6. Artifact response
(<Response>)
 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
SAML security
Principal
Service provider SP
Identity provider IdP
1. Access request
2. Redirect: <AuthnRequest>
TLS for all
connections
3. User login to IdP
4. Redirect with artifact
7. Resource access
5. Resolve artifact
6. Artifact response
<Response> Sign with IdP signature key
 Response must be signed by IdP
 TSL needed for all connections:
– Protects password; protects secrecy of user attributes; prevents
redirections to wrong site
 Attributes in the Response are signed by IdP
15
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
 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 federation
16
Sessions in Shibboleth
 Shibboleth implements two kinds of sessions:
– IdP session between browser and the IdP (IdP cookies)
 user only needs to type in password once
– SP session between browser and each SP (SP cookies)
 Additional application sessions:
– Web middleware incl. PHP, JSP and ASP.NET implements
sessions using cookies, URL or web form)
– Applications may set their own cookies
 No single logout
– Logging out of SP does not usually log the user out of the IdP
 can log back to SP without password
– Logging out of IdP does not log the user out of SPs
– Logging out of one SO does not log the user out of other SPs
 Application sessions complicate the situation further
 Shibboleth logout behavior is hard to understand
17
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 Aura
o = Teknillinen korkeakoulu
eduPersonAffiliation = employee;faculty;member
 Try https://rr.funet.fi/haka/
 User attributes are personal data
 For legal reasons, IdP needs user confirmation before
transferring attributes to SP  the annoying check
box after IdP login
18
CORPORATE IAM
19
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
20
[Internet 2 Middleware Initiative]
21
STRONG IDENTITY
22
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 long since been solved in other ways
 Why not use OpenId or SAML?
– OpenId allows user to choose identifier  no secure link
to a real person
– SAML works internally in organizations and between
organizations that have a contract  not for new, open
online services
23
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?
24
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/
25
Tupas authentication
User
Online service
Bank
1. Bank selection
2. POST redirection
TLS for all
connections
3. One-time password login to bank
4. POST redirection: name,
name,national
nationalididnumber,
number,MAC
MAC
5. Service access
Authenticated with
a shared key;
id number (Hetu)
may be encrypted
 Three-corner authentication model: user, user’s bank, online
service
 Each service must set up a shared key with each bank
Smaller banks are not supported by all online services
26
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
– Requires identity proofing i.e. checking if the subject identity
before issuing the certificate (now done with Tupas in Finland)
– Operators want a fee for every transaction  low number of
transactions  may not be a viable business
27
Reading material
 Online:
– OpenId 2.0, http://openid.net/developers/specs/
– SAML 2.0 Technical Overview, http://www.oasisopen.org/committees/download.php/27819/sstcsaml-tech-overview-2.0-cd-02.pdf
28
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?
 How much difference does it make to security and privacy if the userprovided 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?
 Compare the logout (and re-login) behavior of Noppa, Oodi and
nelliportaali.fi. Which sessions get deleted, when and how?
 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?
29