Aalto University autumn 2011 Outline Single signon OpenId SAML and Shibboleth Corporate IAM Strong identity 2 Single signon SSO Users have too many user accounts Cannot remember the passwords ID: 625663
Download Presentation The PPT/PDF document "Identity management" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Identity management
Aalto
University
,
autumn
2011Slide2
Outline
Single sign-on
OpenId
SAML and ShibbolethCorporate IAMStrong identity
2Slide3
Single sign-on (SSO)
Users have too many user accounts
Cannot remember the passwords
Service access slow and inconvenientForgotten, 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 servicesFederated SSO: authentication between administrative domainsMain problem with SSO systems: there’re so many of them
3Slide4
OpenId
4Slide5
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 sitesEnd user authenticates to RP with the help of OPThe end user needs a web browser i.e. user agent (UA)5Slide6
OpenId 2.0 protocol
Identifier is an
HTTP URL
(or XRI): gives the OP addresse.g. username.myopenid.com, https://me.yahoo.com/usernameDirect messages use
HTTP POST
Indirect messages use
HTTP redirectData fields sent as URL parameters via the browserMethod of user authentication not specified; typically a password6Slide7
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 stepUA 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 passwordCheck RP name presented by OP to approve login7Slide8
OpenId notes
What does “open” mean?
Anyone can become an identity provider
User can choose any identity providerServices accept the identity chosen by the userWorks on any web browser without proprietary softwareIn practice, not always so open:
RP policy may determine which OPs
are accepted
OP policy may determine which RPs are acceptedUser-provided id may just point to OP without identifying the usere.g. https://www.google.com/accounts/o8/idOpenId specification is poorly writtenAssumes the reader knows previous versionsUses 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
8Slide9
SAML and
Shibboleth
9Slide10
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 metadataPrincipal (= user, subject) registers with the IdPPrincipal authenticates to IdP and SP10Slide11
SAML
SAML is a complex family of protocols:
Assertions
are statements by IdP about a principal, written in XMLProtocols 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 bindingsMetadata defines trust relationsUnlike OpenId, SAML is based on contractual relationsMetadata must be exchanged between IdP and SPFederation may set rules for its member IdPs and SPsUser cannot decide which id to use whereTypical profile: SAML web browser SSO profile
11Slide12
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 redirectionPOST: message between SP and IdP is sent in HTTP form via browser, with the help of user or scriptArtifact: reference to message is sent in GET URL via browser, with the help of HTTP redirection, and the actual message is retrieved directly from senderOther profiles support SOAP bindings12Slide13
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 combinations13Slide14
SAML web browser SSO profile
Example:
redirect-artifact binding
: SP sends <AuthnRequest> to IdP in GET URL with HTTP redirectIdP sends an artifact to SP in GET URL with HTTP redirectSP retrieves <Response> from
IdP
with artifact resolution protocol
14Slide15
SAML security
Response must be signed by
IdP
TSL needed for all connections:Protects password; protects secrecy of attributes; prevents redirection to wrong siteAttributes in Response signed by IdP
15Slide16
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 existIf SP supports multiple IdPs, SP-initiated authentication goes via the where are you from (WAYF) pageOne more step of redirection for the AuthnRequestTwo 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 federation
16Slide17
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 metadataExample: cn = Tuomas Aura
o =
Teknillinen
korkeakoulu eduPersonAffiliation = employee;faculty;memberTry 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
17Slide18
Corporate IAM
18Slide19
Corporate IAM
Federated identity and authentication is not sufficient:
Need to
configure access permissions for users in the servicesNeed to monitor access control state in the systemNeed to revoke access rights
Identity and access management (IAM)
systems
Define roles and groups for the organization Enable centralized role assignment, revocation and monitoringExample:student enrolls to university, then becomes employee, then graduates, finally leaves employmentCentral IAM server and IAM agent at each supported service more expensive to develop and deploy than federated authentication
19Slide20
20
[Internet 2 Middleware Initiative]Slide21
Strong
identity
21Slide22
Strong authentication
Goal:
authentication equivalent to verifying
national identity card or passportWhy is it needed?Initial id check when registering new users, e.g. students enrolling to universityRequired 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 personSAML works internally in organizations and between organizations that have a contract not for new or ad-hoc relations22Slide23
Finnish electronic identity card
Finnish identity cards (
HST-
kortti) have a smartcard chip with three key pairsSignature, encryption and authentication keyshttp://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?
23Slide24
Tupas authentication
Tupas
uses bank accounts for strong authentication
Defined by Federation of Finnish Financial Serviceshttp://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 proofingExample: https://password.aalto.fi/ 24Slide25
Tupas authentication
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
25Slide26
Mobile signature
Mobile phone operators
install a
signature key on the SIMETSI standardDeveloped 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 revocationFour-corner authentication model:Mobile operators have contracts with each otherEach service and user only needs to have a contract with one operatorDeployment and adoption has been slowHeavy requirements for identity proofingOperators want a fee for every transaction low number of transactions no business model
26Slide27
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
27Slide28
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