SOA Certification Mentoring

20 March 2008

Session 8: SOA Security

1

SOA Certification Mentoring

Session 8SOA Security

20 March 2008


2

Session 8 Agenda

• Notes• Next steps• Questions about the reading?• SOA Security topics

20 March 2008


3

Reminder

• Register for a timeslot to take the exam.

20 March 2008


4

Assignment for next week – Review

• Review the previous presentations and podcasts

• Review the exam outlines from the web:

– 664: http://www-03.ibm.com/certify/tests/obj664.shtml

– 667: http://www-03.ibm.com/certify/tests/obj667.shtml

• Gut check – do you feel ready?

20 March 2008


5

Questions about the reading?

• Read the following sections from the Rebook “Understanding SOA Security”:

– Section 1.1.1 – 1.1.3, 1.3; Chapters 2-6

• http://www.redbooks.ibm.com/abstracts/SG247310.html

20 March 2008


6

Security Considerations for SOA

• The need for identity to be decoupled from services.

• The need to manage identity and security across a range of systems and services that are implemented in a diverse mix of new and old technologies

20 March 2008


7

Siloed Applications Lead to SiloedIdentities

Division “A” Division “B” Division “C” Division “D” Division “E”ray divb-ray [email protected]

mgr

z42

20 March 2008


8

Service Reuse Leads to Identity Propagation Conflicts

Outsourced

SupplierSupplier

Shared ServicesShared Services

Division (s)

CustomerCustomer

ray

divb-ray

ibm_empl

[email protected]

ibm_23

mgr

z42

20 March 2008


9

Security Considerations That Haven’t Changed

• The need to protect business data both in transit and at rest.

• The need for demonstrable compliance with changing regulatory requirements

20 March 2008


10

Key Message

• “The overall security principles that apply in any environment, whether SOA or not, are the same: identity, authentication, authorization, confidentiality, integrity, audit and compliance, policy management and availability. What changes in SOA is how they are applied.”

-p16 “Understanding SOA Security Design and Implementation” Redbook

20 March 2008


11

Web Services Security Standards

20 March 2008


12

SOAP Foundation

20 March 2008


13

WS-Security

• The WS-Security specification provides message-level security. The advantage of using WS-Security instead of Secure Sockets Layer (SSL) is that it can provide end-to-end message level security. This means that the messages are protected even if the message goes through multiple services, or intermediaries. Additionally, WS-Security is independent of the transport layer protocol. It can be used for any SOAP binding, not just for SOAP over HTTP.

20 March 2008


14

WS-Security

20 March 2008


15

WS-Security Example

20 March 2008


16

WS-Policy

• WS-Policy provides a flexible and extensible grammar for expressing the capabilities, requirements, and general characteristics of entities in an XML Web services-based system. WS-Policy defines a framework and a model for the expression of these properties as policies. Policy expressions allow for both simple declarative assertions as well as more sophisticated conditional assertions.

20 March 2008


17

WS-Trust

• The Web Services Trust Language (WS-Trust) uses the secure messaging mechanisms of WS-Security to define additional primitives and extensions for the issuance, exchange, and validation of security tokens. WS-Trust also enables the issuance and dissemination of credentials within different trust domains.

20 March 2008


18

WS-SecureConversation

• The Web Services Secure Conversation Language (WS-SecureConversation) is built on top of the WS-Security and WS-Policy models to provide secure communication between services. WS-Security focuses on the message authentication model, but not a security context, and thus is subject to several forms of security attacks. This specification defines mechanisms for establishing and sharing security contexts, and deriving keys from security contexts, to enable a secure conversation.

20 March 2008


19

WS-Federation

• WS-Federation describes how to use the existing Web services security building blocks to provide federation functionality, including trust, single sign-on (and single sign-off), and attribute management across a federation. WS-Federation is really a family of three specifications: WS-Federation, WS-Federation Passive Client, and WS-Federation Active Client.

20 March 2008


20

SAML

• Security Assertion Markup Language (SAML) is a specification designed to provide cross-vendor single sign-on interoperability. SAML was developed by a consortium of vendors (including IBM) under the auspices of OASIS, through the OASIS Security Services Technical Council (SSTC). SAML has two major components: It describes SAML assertions used to transfer information within a single sign-on protocol and SAML bindings and profiles for a single sign-on protocol.

20 March 2008


21

XACML

• eXtensible Access Control Markup Language (XACML) is an initiative to develop a standard for access control and authorization systems. It describes both a common language for expressing access control policies to describe general access control requirements and a request/response language that describes how to form a query to determine if a given action is allowed or not and how to interpret the result. XACML addresses several use cases: – Define a policy – Gather required data for policy evaluation – Evaluate policy – Enforce policy

20 March 2008


22

SAML with XACML

1. An XACML Policy Enforcement Point (PEP) receives a request to access some resource.2. The PEP obtains SAML Assertions containing information about the parties to the request, such as the

requester, the receiver (if different) or intermediaries. These Assertions might accompany the request or be obtained directly from a SAML Authority, depending on the SAML profile used.

3. The PEP obtains other information relevant to the request, such as time, date, location, and properties of the resource.

4. The PEP presents all the information to a Policy Decision Point (PDP) to decide if the access should be allowed.

5. The PDP obtains all the policies relevant to the request and evaluates them, combining conflicting results if necessary.

6. The PDP informs the PEP of the decision result.7. The PEP enforces the decision, by either allowing the requested access or indicating that access is not

allowed.

20 March 2008


23

RACF

• Resource Access Control Facility (RACF) is an add-on software product that provides security for a mainframe system. RACF protects resources by granting access only to authorized users of the protected resources. RACF retains information about users, resources, and access authorities in special structures called profiles in its database, and it refers to these profiles when deciding which users should be permitted access to protected system resources.

20 March 2008


24

IBM’s Security Products (partial list)

• Tivoli Identity Manager (TIM)• Tivoli Access Manager (TAM)• Tivoli Federated Identity Manager

(TFIM)• DataPower XS40 and XI50

20 March 2008


25

Tivoli Identity Manager (TIM)

• IBM Tivoli Identity Manager provides a secure, automated and policy-based user management solution that helps effectively manage user identities throughout their lifecycle across both legacy and e-business environments

20 March 2008


26

Tivoli Access Manager (TAM)

• IBM Tivoli Access Manager is an award-winning, policy-based, access control security solution for e-business and enterprise applications, featuring Web-based single sign-on and distributed Web-based administration.

20 March 2008


27

How TIM Relates to TAM

Enterprise level:User provisioning

Enterprise level:User provisioning

TIM TIM SystemsSystems

ApplicationsApplications

DatabasesDatabases

AuthorizationAuthorizationTAMTAM

AccountsAccounts

DMZDMZInternet Private Private Network Network

CHECK

AccountsAccountsAccountsAccountsAccountsAccounts

20 March 2008


28

Tivoli Federated Identity Manager (TFIM)

• Tivoli Federated Identity Manager is a standards-based, access control solution for federated single sign-on (SSO) and trust management in a web services & SOA environments.

20 March 2008


29

TFIM – Identity Propagation in SOA

• Provides “in the plumbing” services for:– Passing identity between domains – what userid and how is it passed– Authorization (via calls to TAM)– Audit logging

• Integration with IBM’s Enterprise Service Bus offerings– WebSphere Enterprise Service Bus– WebSphere Message Broker– Datapower XI50

• Integration with:– WebSphere Application Server– WebSphere Portal Server– RACF/CICS and other “legacy” applications

• REFERENCE:– http://www.redbooks.ibm.com/abstracts/sg247310.html

20 March 2008


30

Implementation of WS-Trust in TFIM

TrustClient

TFIMSecurity Token Service (STS)

(Trust Chain)

Issuer, AppliesTo, <Token>

StatusCode, <NewToken>

WebSphere Application Server(inbound/outbound SOAP, JCA, JDBC)

WebSphere Enterprise Service BusWebSphere Message BrokerDataPower SOA Appliances (XS40,XI50)

WS-Trust

20 March 2008


31

Example Credential Flow

ClaimsPortal

ClaimsMediation

ClaimsService

ClaimsDB

TFIM STS

swarnepassw0rd

swarne Shane.Warne

warniepassword1

WebLogin SAML 2.0

WS-Sec

JDBC

SAML 1.1WS-Sec

WAS3

ESB WAS2WAS1

WS-Trust

WebSEAL

TAIswarne

HTTPHdr

20 March 2008


32

DataPower for security and connectivity

20 March 2008


33

DataPower as a Web 2.0 security appliance

20 March 2008


34

IBM SOA Security Reference Model

20 March 2008


35

IBM SOA Security Reference Model

20 March 2008


36

For More Informationhttp://www.redbooks.ibm.com/redpieces/abstracts/REDP4354.html?Open

20 March 2008


37

For More Informationhttp://www.ibm.com/developerworks/library/specification/ws-secure/

20 March 2008


38

Fin

SOA Certification Mentoring

Documents

Transcript of SOA Certification Mentoring