federated identity management452

8/13/2019 Federated Identity Management452

1/28

Federated Identity Management

California Enterprise Architecture Program

The State of California

The Bluepr int

October 29, 2007

Draft


2/28

California Enterprise Architecture Program 2California Enterprise Architecture 2

The Future is Here

Offer new business services on the web Move from silo application environment to an

SOA environment

Business services implemented as web services

Shared services across public and private

Web services require a new security model

Federal Guide to Web Services Security

(NIST 800-65) August 2007http://csrc.nist.gov/publications/nistpubs/800-65/SP-800-65-Final.pdf
http://csrc.nist.gov/publications/nistpubs/800-65/SP-800-65-Final.pdfhttp://csrc.nist.gov/publications/nistpubs/800-65/SP-800-65-Final.pdfhttp://csrc.nist.gov/publications/nistpubs/800-65/SP-800-65-Final.pdfhttp://csrc.nist.gov/publications/nistpubs/800-65/SP-800-65-Final.pdfhttp://csrc.nist.gov/publications/nistpubs/800-65/SP-800-65-Final.pdfhttp://csrc.nist.gov/publications/nistpubs/800-65/SP-800-65-Final.pdfhttp://csrc.nist.gov/publications/nistpubs/800-65/SP-800-65-Final.pdfhttp://csrc.nist.gov/publications/nistpubs/800-65/SP-800-65-Final.pdfhttp://csrc.nist.gov/publications/nistpubs/800-65/SP-800-65-Final.pdfhttp://csrc.nist.gov/publications/nistpubs/800-65/SP-800-65-Final.pdfhttp://csrc.nist.gov/publications/nistpubs/800-65/SP-800-65-Final.pdfhttp://csrc.nist.gov/publications/nistpubs/800-65/SP-800-65-Final.pdf


3/28


WS Security Standards Model

Federal Guide to Security Web Services (NIST 800-65 August 2007)


4/28


Web Services Security

Key Elements according to Federal Guide to SecuringWeb Services (NIST 800-65, August 2007)

Confidentiality of Web service messages using XML

Encryption (W3C standard)

Integrity of Web service messages using XMLSignature (W3C) and X.509 certificates (IETF)

Web service authentication and authorization

SAML, XACML (OASIS standards)

Web Services Security (OASIS standard) End-to-end SOAP messaging security

Security for Universal Description, Discovery, and

Integration (UDDI) (OASIS standard)


5/28


SOA Reference Architecture

UsersBrowsers Voice

Channel PC PDA Cell Phone IPhone IVR

UserInterface

Platform Mainframe UNIX Windows .NET Java J2EE COBOL CICSSystem

Administration

Network Firewalls Routers XML Accelerators Proxy Servers TCP/IPNetwork

Administration

Security,O

perations,&

Gove

rnance

Policy,Process,Mo

nitoring,Reporting,U

sageTracking

Web

Services

Atomic Composite

Data Access

Business

Logic/Rules

Federated

Service

Management

Enterprise

Service Bus

Service Registry

Orchestrated Web Services

Service Discovery

Service Transformations

Service Mediation, Routing, Logging, Auditing

Identity Policy Enforcement

Messaging

Management

AuthenticationSingle Sign-On

Business Process

Access PointsPortals / Websites

Web Applications ASP JSP HTML CSS

UserInteractionsVoice/XML


6/28


SOA Identity Management Key Areas

Conceptual Architecture Levels of Authentication

Authentication Attributes

Identity Providers

ESB and Service Registry

Security Policy Service

Service Providers

Web Applications Virtual Directory Service

Identity Resolution Service

Provisioning Users

Single Sign-On (SSO)

Example Scenarios

Governance

Note: Scenario examples are illustrated at theend of the presentation


7/28


Identity Management & SOA

Phone

CallCenter

VoicePortal

Web

WebPortal

EnterpriseSOA

Infrastructure

Web ServiceManagement

Web ServiceMonitoring

andReporting

Smart

Clients

Web Services

Verify SSN

MedsEligibility

AddressChange

Prof LicenseVerification

VitalStatistics

ServiceProviders

DHCS DMH

DMV

FTB

LA County

CalRHIO

Business Partner

DOT

CDCR

EDD

OSHPD

DCA

StateEmployee

Users

Individual

BusinessPartner

CountyEmployee

Etc.

WebService

IdentityProviders

StateEmployees

Individuals

BusinessPartners

Basic

SecurityInfrastructure

Authentication

Authorization

Provisioning

Auditing

EnterpriseSecurity

Policy Service

VirtualDirectory

Service

Security Attributes


8/28


Assumptions

Different models for some user classes

One size does not fit all

Both Local and Enterprise environments

Multi-vendor environments

May need identity resolution if no single truth foridentity information

May need virtual directory service if identityinformation are not in a single repository

Degree of opt in TBD for individuals

Drives identity architecture for this user class CardSpace, self registration, rules for sharing identity

information, SAML 2.0, etc.


9/28


10/28


Business Partner IDM Model

BusinessPartner 1

Business

Partner Web

App

E

n

t

er

p

r

i

s

e

E

S

B

Enterprise

Service

Registry

SOAGovernance

(Security

Policies)

SharedShared

WebWeb

ServiceService

Policy

Enforcement

Point

ServiceService

ProvidersProviders

SOA Identity Management

Business Partners

Audit

Service

Note: Business Partners could provide their own identity

service, group together and share an identity service, or the

State could provide identity services for certain classes of

business users.

Business

Partner 2

(Successful, Business

ID, User ID, Role 1)

SOAP/SAMLToken

LocalAuthentication

andAuthorization

IdentityIdentity

ProviderProvider

ServiceService

IdentityIdentity

ProviderProvider

ServiceService

IdentityIdentity

ProviderProvider

ServiceService

IdentityIdentity

ProviderProvider

ServiceService

IdentityIdentity

ProviderProvider

ServiceService

Login Page

(User ID, Business

ID, Role 1)

Business

Partner Identity

Service

TokenService

Virtual

Directory

Service

TokenToken

ServiceServiceTokenToken

ServiceServiceTokenToken

ServiceServiceServiceService

Register Service

(Optional)


11/28


Individual IDM Model

Citizen

Web App

E

n

t

e

r

p

r

i

s

e

E

S

B

Enterprise

Service

Registry

SOA

Governance

(Security

Policies)

SOA Identity Management

Individuals

SAML Token

(Succ/Fail, Other

attributes)

(UiD, Pwd, PIN, other

attributes)

SOAP/SAMLAssertion

Emp ID

Success

Role 1

Role 2

Audit

Service

Note: Optional, do basic

authentication at the State Portal? Note: Identity Resolution needed if no

single truth for identity information.

Login Page

State PortalState Portal

Individual

Identity

Service

Virtual

Directory

Service

Identity

Resolution

Token

Service

Basic

Identity

Service

UID, PWD

Token

Service

Note: Need to accommodate both

CardSpace and SAML 2.0. Degree

of user opt-in TBD.

SharedShared

WebWeb

ServiceService

Policy

Enforcement

Point

ServiceService

ProvidersProviders

Register Service

(Optional)

(Optional)

Note: Virtual Directory Service needed if

identity information in multiple locations.


12/28


Authentication Levels Level 1 Basic

UserId and Password, Challenge-Response protocol

Level 2 Single Factor

Shared secrets, Identity Provider, SAML

Level 3 Multi-factor Identity Provider, SAML, X.509 certificates

Software tokens (digitally signed and encrypted)

Hardware tokens (smart cards, etc.)

One time passwords Level 4 Hardware (physical) tokens only

Typically BIO (fingerprint, voice recognition, etc.)

Federal Electronic Authentication Guideline (NIST 800-63)http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf
http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdfhttp://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdfhttp://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdfhttp://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdfhttp://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdfhttp://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf


13/28


Authentication Attributes Attributes that identify me

Name, Address, DOB, Gender, Fingerprint, BirthCertificate, etc.

Shared secrets

Mothers maiden name, favorite dogs name, etc.

Identifiers assigned to me UserId, Pwd, PIN, Drivers License, SSN, EmployeeId,

Account Number, TaxpayerId, MedsId, etc.

Identifiers assigned to my employer

EmployerId, FEIN, etc.

Attributes may be combined into authentication profiles

Individual, State Employee, County Employee,Incorporated Business, Professional Business, etc.


14/28


Identity Providers Performs authentication for a class of users based on

the security policy

Individual, State Employee, Business Partner, CountyEmployee, etc.

SAML 2.0 (OASIS standard ) is the preferred

protocol and token Only Identity Providers can access the Security

Policy Serviceso, minimize the number of IdentityProviders

Responsible for creating the SAML token(credential)

Trust relationship with Service Providers


15/28


ESB & Service Registry

Provides service transparency and flexibility Only the Service Registry knows where the

services are actually located

All client web applications point to the ESB

ESB provides message routing, transformation,mediation, logging, connectivity to other system

components, and optionally, rules based routing

Only authorized users can create or modify

information in the Service Registry. If UDDI v.3compliant, users looking up a service can also be

restricted


16/28


Security Policy Service Single (logical) repository for security policies for all

shared services (highly available and scalable)

Often included in SOA Governance products, whichmay be bundled with the service registry

Could include:

Authentication type (Individual, State Employee, etc.) Authentication level (1, 2, 3, or 4)

Required attributes (UId, Pwd, Drivers License, etc.)

Attribute encryption

Optional? Only administrators located in the ServiceCertification Environment can create/modify policies inthe repository

Act as proxies for the Service Providers


17/28


Service Providers

Implement business services as web services Can be shared externally, internally, or private

Set the security policy for the service

Publish service information to the Service Registry,

and security information to the Security Policy Service May be written in any language that complies with

web service standards (.NET, JAVA, CICS, etc.)

Can be part of an orchestration of web services, or

call other web services

Are usually protected by a Policy Enforcement Point

(proxy server, XML gateway, etc.)


18/28


Web Applications

Responsible for the user session and interface(web pages)

Determine if security is required for a given

interaction

Ask user for attribute information via a loginform (based on request from an Identity

Provider). For example, UserId, Pwd, Drivers

License number, etc.

Create the SAML assertion or manage CardSpace

card


19/28


Virtual Directory Service

Needed if identity information is stored inmore than one location.

Accommodates data federation

Can connect to different formats (LDAP,

Active Directory, Tivoli, SQL database, etc.)

Some products can map attributes to a

profile


20/28


Identity Resolution Service (optional)

Note: Access to the Identity

Resolution Service limited to

Identity Providers in a Circle of

Trust. Could further limit at the

attribute level.

IdentityResolution Service

Master PersonProfile

Name, Addr, City,State, Zip, DOB,Gender, DL, SSN,Passport,Fingerprint, BirthCertificate, MedsId,UserId, Pwd, PIN

IndividualIdentityService

Master PersonProfile

StateEmployeeId Service

Master StateEmployee Profile

DOJ

Name: Jonathan LandersAddr: 1234 Cimarron Dr.City: SacramentoDOB: 10/19/1970Passport: 12345678

DMV

Name: John LandersAddr: 1234 MassachusettsCity: SacramentoDOB: 10/19/1970Gender: MDrivers License: M123456Fingerprint: Y

DMV

Name: Johnny LandersAddr: 1234 Simeron Dr.City: SacramentoDOB: 10/19/1970Gender: MDrivers License: M123456Fingerprint: Y

DHCS

Name: John E. LandersAddr: 1324 Cimarron Dr.City: Sacramento

DOB: 10/19/1970SSN: 512-00-1234MedsId: X3984PBirth Certificate: YState Portal

Name: John LandersAddr: 1234 Cimarron Dr.City: SacramentoDOB: 10/19/1970UserId: jlandersPwd: xxxx

Note: Minimal changes toexisting databases and

provisioning systems.

Example: Individual ID Service could

only access Master Person Profile, or

FEIN attribute is excluded.

Note: Could enhance

fraud detection.

Note: Could be

anonymous. That is,

the identity providersdont need to know

the source of the

attribute information.


21/28


Provisioning Users

Depends on the following policies: Will there be a single truth for a given user?

Will all user attributes be in one location?

Will the State Portal handle some level of

authentication?

Level of user opt-in

Trust model


22/28


Web Single Sign-On (SSO)

Circle of Trusts Small number of Identity Providers

Based on SAML

Depends on security policies

Additional attributes might be required

Higher level authentication might be required

Reduced sign-on is probably achievable

E l S i


23/28


Example Scenario

Individual UserState Portal

Individual

UserUpdate address

Security Policy

Service

Policies

Get Policy:

(UserId, Pwd, Pin)

ESBService

Registry

Certification

Process

Desc

Location

WSDL

UDDI V3

Only administrators in the Service Certification

environment are allowed to insert/update/delete servicepolicies. They act as proxies for the Web Service

Providers. This limits the number of connections into

the Security Policy Service.

Must be standards based.

Vendor neutral, but supported by major vendors.

Web App

Basic Identity

Service

Provisioning

State Portal

SAML

Assertion

SAML

Token

Level 1 or 2

(UiD, Pwd, PIN)

Invoke Web Service

(SOAP/SAML)

authenticate=yes

Retrieve additional

attributes

Authentication

RepositoryVirtual

Directory

Service

Token

Service

Login Page

UserIdPwd

PIN

Policy

Enforcement

Point

Address Web

Service

Service Provider


24/28


Example Scenario

Individual UserAll levels

Individual

UserUpdate address

Security Policy

Service

Policies

Auth type, level

Attributes required

ESBService

Registry

Desc

Location

WSDL

UDDI V3



Web App

State PortalInvoke Web Service

(SOAP/SAML)

authenticate=yes

Retrieve additional

attributes

VirtualDirectory

Service

Individual

Identity ServiceToken

Service

Authenticdation

Repository

Get Policy

(Uid, Pwd, Pin)Provisioning

Address Changed Notification Service would

be a good candidate for a BPEL process

Login Page

UserIdPwd

PIN

Policy

Enforcement

Point

Address Web

Service

Address

Changed

Notification

Service

Service Provider

Authentication Request

(SOAP/SAML)


25/28


Example Scenario Business Partner

Business

PartnerCheck Medi-Cal

Eligibility

Security Policy

Service

Policies

Get Policy:

(BusID, EmpID,

Meds Elig Role,

Encrypted, Signed)

Auth type, level

Attributes required

ESBService

Registry

Desc

Location

WSDL

UDDI V3



Web App

Identity Service

Business Partner

Invoke Web Service

(SOAP/SAML)

Retrieve additional

attributes

Virtual

Directory

Service

Policy

Enforcement

Point

DHCS Meds

Eligibility Web

Service

Service Provider

Login Page

SOAP/SAML

State Enterprise Environment

Note: Must be trusted relationship

between Identity Service, Security PolicyService, and Meds Eligibility Web Service

Meds

Data


26/28


Governance Matrix


27/28


Roadmap

Q3 07 Q3 08

SOA & IDM vision

SOA Governance GroupAdopt vision

Enterprise SOA Infrastructure

Enterprise Identity Management Infrastructure

Individual Identity Service

State Employee Identity Service

County Employee Identity Service

Business Partner Identity Services

Q4 07 Q1 08 Q2 08 Q4 08

Provide Interoperability Standards

Establish Service Certification Process

Recommendations for Sustaining Enterprise SOA

Publish Standard SOA & IdM Language

State CIO set SOA & IdM Policy

Enterprise SOA & IdMRoadmap

Make PKI decision


28/28

California Enterprise Architecture Program 28

Questions

[email protected]

916-739-7637
mailto:[email protected]:[email protected]

federated identity management452

Documents