/
Identity management Identity management

Identity management - PowerPoint Presentation

debby-jeon
debby-jeon . @debby-jeon
Follow
448 views
Uploaded On 2017-03-20

Identity management - PPT Presentation

Aalto University autumn 2012 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: 526988

saml user idp identity user saml identity idp openid authentication sso http browser web service access security shibboleth url online attributes message

Share:

Link:

Embed:

Download Presentation from below link

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.


Presentation Transcript

Slide1

Identity management

Aalto

University

,

autumn

2012Slide2

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

SSO types:

Pseudo-SSO

: separate authentication to each service; client software manages the credentials and hides the login from userProxy-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 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 GET and Redirect

Data 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 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: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 the OP name in the browser address bar before typing in the passwordCheck RP name on OP login page before approving 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 accepted

For privacy, user-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 implementation, 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 then to SP

10Slide11

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 first exchanged between IdP and SPFederation may set rules for its member IdPs and SPs

User cannot decide which id to use where

Typical 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, submitted by user click 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 senderSOAP binding not used in this profile

12Slide13

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 user attributes; prevents redirections to wrong siteAttributes in the Response are signed by IdP

15Slide16

Shibboleth 2

Open-source implementation of SAML 2.0 for web

SSO

(wiki)Developed by the Internet 2 projectUsed 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) pageOne more step of redirection for the AuthnRequestFederation 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

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 onceSP 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

17Slide18

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://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

18Slide19

Corporate IAM

19Slide20

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

20Slide21

21

[Internet 2 Middleware Initiative]Slide22

Strong

identity

22Slide23

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 universityRequired 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 waysWhy 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 services23Slide24

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?

24Slide25

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/ 25Slide26

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

26Slide27

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 otherEach service and user only needs to have a contract with one operatorDeployment and adoption has been slowRequires 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

27Slide28

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

28Slide29

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 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?

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