Beruflich Dokumente
Kultur Dokumente
Draft
California Enterprise Architecture Program
Web services require a new security model Federal Guide to Web Services Security (NIST 800-65) August 2007
http://csrc.nist.gov/publications/nistpubs/800-65/SP-800-65-Final.pdf
22
33
Security for Universal Description, Discovery, and Integration (UDDI) (OASIS standard)
California Enterprise Architecture Program California Enterprise Architecture
44
Portals / Websites Web Applications ASP JSP HTML CSS Voice/XML Orchestrated Web Services Service Discovery Service Transformations
Mainframe UNIX Windows .NET Java J2EE COBOL CICS Firewalls Routers XML Accelerators Proxy Servers TCP/IP
System Administration
Network Administration
55
66
Enterprise SOA Infrastructure Web Service Management Web Service Monitoring and Reporting
FTB DHCS
DMH OSHPD DOT DMV CDCR LA County Business Partner EDD CalRHIO DCA
Service Providers
Voice Portal Web Portal Authentication Authorization Provisioning Smart Clients Auditing
Virtual Directory Service
Web Services Verify SSN Meds Eligibility Address Change Prof License Verification Vital Statistics
Web
Identity Providers
Basic
Web Service
Security Attributes
Business Partners
77
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 for identity information May need virtual directory service if identity information 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.
88
Web App
Role 1 Role 2
E n t e r p r i s e E S B
Token Service
Audit Service
Service Providers
Policy Enforcement Point
Register Service
99
SOAP/SAMLToken
(Successful, Business ID, User ID, Role 1)
E n t e r p r i s e E S B
Token Service
(Optional)
Business Partner 2
(User ID, Business ID, Role 1)
Service Providers
Policy Enforcement Point
Register 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.
10 10
SOAP/SAMLAssertion
(UiD, Pwd, PIN, other attributes)
Web App
E n t e r p r i s e E S B
Token Service
(Optional)
Identity Resolution
(Optional)
Audit Service
Service Providers
Policy Enforcement Point
State Portal
Note: Optional, do basic authentication at the State Portal? Note: Need to accommodate both CardSpace and SAML 2.0. Degree of user opt-in TBD.
Note: Identity Resolution needed if no single truth for identity information. Note: Virtual Directory Service needed if identity information in multiple locations.
11 11
Authentication Levels
Level 1 Basic
UserId and Password, Challenge-Response protocol
Level 3 Multi-factor
Identity Provider, SAML, X.509 certificates Software tokens (digitally signed and encrypted) Hardware tokens (smart cards, etc.) One time passwords
12 12
Authentication Attributes
Attributes that identify me
Name, Address, DOB, Gender, Fingerprint, Birth Certificate, 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.
Identity Providers
Performs authentication for a class of users based on the security policy
Individual, State Employee, Business Partner, County Employee, etc.
SAML 2.0 (OASIS standard ) is the preferred protocol and token Only Identity Providers can access the Security Policy Service so, minimize the number of Identity Providers Responsible for creating the SAML token (credential) Trust relationship with Service Providers
14 14
Optional? Only administrators located in the Service Certification Environment can create/modify policies in the repository
Act as proxies for the Service Providers
California Enterprise Architecture Program California Enterprise Architecture
16 16
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.)
California Enterprise Architecture Program California Enterprise Architecture
17 17
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 login form (based on request from an Identity Provider). For example, UserId, Pwd, Drivers License number, etc. Create the SAML assertion or manage CardSpace card
California Enterprise Architecture Program California Enterprise Architecture
18 18
19 19
Note: Minimal changes to existing databases and provisioning systems. Note: Could enhance fraud detection. Note: Could be anonymous. That is, the identity providers dont need to know the source of the attribute information.
DOJ
Identity Resolution Service Name: Jonathan Landers Addr: 1234 Cimarron Dr. City: Sacramento DOB: 10/19/1970 Passport: 12345678
DHCS
Name: John E. Landers Addr: 1324 Cimarron Dr. City: Sacramento DOB: 10/19/1970 SSN: 512-00-1234 MedsId: X3984P Birth Certificate: Y
State Portal
Name: John Landers Addr: 1234 Cimarron Dr. City: Sacramento DOB: 10/19/1970 UserId: jlanders Pwd: xxxx
Note: Access to the Identity Resolution Service limited to Identity Providers in a Circle of Trust. Could further limit at the attribute level.
Example: Individual ID Service could only access Master Person Profile, or FEIN attribute is excluded.
20 20
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
21 21
22 22
UDDI V3 authenticate=yes ESB Invoke Web Service (SOAP/SAML) Service Registry Desc Location WSDL
Login Page
State Portal
Web App
Service Provider
SAML Assertion
SAML Token
Policy Enforcement Point Security Policy Service Certification Process Policies Address Web Service
Provisioning
Authentication Repository
Only administrators in the Service Certification environment are allowed to insert/update/delete service policies. They act as proxies for the Web Service Providers. This limits the number of connections into the Security Policy Service. Retrieve additional attributes
23 23
UDDI V3 authenticate=yes ESB Invoke Web Service (SOAP/SAML) Service Registry Desc Location WSDL
Login Page
State Portal
Web App
Service Provider
Authentication Request (SOAP/SAML) Individual Identity Service Get Policy (Uid, Pwd, Pin) Auth type, level Attributes required Security Policy Service Address Web Service Authenticdation Repository Policies Retrieve additional attributes Virtual Directory Service Address Changed Notification Service Policy Enforcement Point
Token Service
Provisioning
Address Changed Notification Service would be a good candidate for a BPEL process
24 24
Login Page
Service Registry
Business Partner
Web App Invoke Web Service (SOAP/SAML)
Service Provider
SOAP/SAML Policy Enforcement Point
Identity Service
Get Policy: (BusID, EmpID, Meds Elig Role, Encrypted, Signed) Security Policy Service Auth type, level Attributes required
Note: Must be trusted relationship between Identity Service, Security Policy Service, and Meds Eligibility Web Service
25 25
Governance Matrix
26 26
Roadmap
SOA & IDM vision SOA Governance Group Adopt vision
Q3 07
Q4 07
Q1 08
Q2 08
Q3 08
Q4 08
27 27
Questions
Lee.Macklin@ceap.ca.gov 916-739-7637
28 28