accelerate secure and integrate with ibm websphere datapower soa appliances - vol 2

7/21/2019 Accelerate Secure and Integrate With IBM WebSphere DataPower SOA Appliances - Vol 2

1/314

901 100 400

ibm.com/train

ing/es


2/314

IBM

Training

-

-

-

-r-

--rf

-

Accelerate,

Secure

and

lntegrate

with

IBM

WebSphere

DataPower SOA

Appliances

(Course

code

W8555

/

V8555) TOMO

ll

Student

Notebook

ERC

2.0

@e-

.

i

rrarnrng

WebSphere

Education

E

color

azul de

la

impresin

garantiza

la autentlcidad de este docunrento

O Copyright


3/314

ri.g

rr-9

Trademarks

IBM@

is

a

registered

trademark

of

lnternational

Business

Machines Corporation.

The following

are trademarks

of lnternational

Business

Machines Corporation

in

the

United

States, or

other

countries,

or both:

Approach@ DataPower@

DataPower

device@

DB2@ developerWorks@

Domino@

IMSrM

Lotus@

MQSeries@

Notes@

Rational@

RDNTM

Tivoli@

WebSphere@

z/OS@

zSeries@

VMware@

and

the

VMware

boxes

logo and

design,

Virtual SMP

and VMotion

are

registered

trademarks

or

trademarks

(the

Marks )

of

VMware,

lnc.

in

the United

States

and/or other

j

u

risdictions.

Edge

of

Network@ and

ThinkPad@

are trademarks

or

registered

trademarks of

Lenovo in

the United States, other

countries, or

both.

Adobe is

either

a

registered

trademark

or

a

trademark

of

Adobe

Systems

lncorporated

in

the

United

States,

andlor other

countries.

lntel

and Pentium

are

trademarks

or

registered

trademarks

of

lntel

Corporation

or

its

subsidiaries

in

the United

States and other

countries.

Java

and

all Java-based

trademarks

and

logos are

trademarks

of Sun

Microsystems,

lnc.

in

the United

States, other

countries, or

both.

Linux@

is

a

registered trademark

of

Linus

Torvalds

in

the United

States, other countries,

or

both.

Microsoft and

Windows

are

trademarks

of

Microsoft Corporation

in

the

United

States, other

countries,

or both.

UNIX@

is

a

registered

trademark

of

The Open Group

in

the United

States and

other

countries.

Other company,

product,

or service

names may be trademarks

or service

marks of others.

May 2009

edition

The

information

contained

in

this

document

has not been submitted

to

any

formal

IBM

test and

is distrbuted on an

as is basis

without

any warranty either express

or

implied.

Ihe

use of

this

information

or the

implementation

of

any

of

these

techniques

is

a customer

responsibility

and

depends

on

the customer's

ability

to evaluate

and integrate

them

into

the customer's

operational

environment.

While

each item

may

have

been reviewed

by

IBM

for

accuracy

in

a specific

situation, there

is no

guarantee

that

the

same

or

similar

results will

result

elsewhere. Customers attempting to

adapt these techniques

to

their

own environments

do so at their

own

risk.

@ Copyright lnternational

Business

Machines

Corporaton

2009,

All rights

reserved.

This

document

may

not

be

reproduced

n

whole

or

in

pat

wthout

the

prior

written

permission

of

lBM.

Note

to U.S.

Government

Users

-

Documentation

related

to

restricted

rights

-

Use, duplication

or

disclosure

is subject

to

restrictions

set

forth in

GSA

ADP

Schedule Contract

with

IBM

Corp.

O

o

o

o

c

c

o

t^

C

t-

C

t'

('

{

{'

(

(

(

(

(

(

(

(

(

{

(

(

(

(

(

El

color

azul de la mpresin

garantza

la

aLrtenticidad

de

este

documento

O Copyright


4/314

IBM Training

Student

Notebook

Unit

12.

XML

and

Web

servces

securty overview

What

this

unit

is

about

This

unit

discuses the

features of

the

Web

services security

specification.

This

specification

provides

message

level

security

to

ensure

message

confidentiality and

integrity

using

XML

encryption

and

XML signature,

respectively.

You

will learn how

to

use

the

DataPower device to

encrypt

and decrypt,

and to

sign

and

verify

messages.

What

you

should

be

able to do

After completing

this

unit, you should be able

to:

.

Describe the

features of the

WS-Security

specification

.

Enable

message

confidentiality using

XML

Encryption

.

Provide

message

integrity

using

XML

Signature

How

you

will

check

your progress

.

Checkpoint

.

Exercise

10:

Web service encryption and digital signatures

@

Copyright

IBM

Corp.

2009 Unit

12. XML and Web

services security

overview

Course

materials

may

not

be

reproduced

in

whole

or in

part

without the

prior

wrtten

permission

of

lBM.

12-1

El

color azul de la

impresin

garanlza

la autenticidad de este docunrento

@

Copyr

ght


5/314

nmg

-r-o

Unit objectives

,

o

a

|

(,

(

(

(

(

After completing this unit,

you

should

be

able

to:

.

Describe

the features

of the WS-Security specification

.

Enable message confidentiality

using XML Encryption

.

Provide message integrity using

XML

Signature

@

Copyright IBM Corporation

2009

Figure 12-1.

Unit objectives

w8555 / V85552.0

lVofes

12-2

Accelerate,

Secure and

Integrate

with DataPower

@

Copyright IBM

Corp.

2009

Course

materials

may

not

be

reproduced

in whole or

in

part

without the

prior

written

permission

of

lBM.

El

color azul de la

impresin

garant

za la autenticidad de este documento

O

Copyright


6/314

IBM Training

Student

Notebook

Review

of

basic

security

terminology

o

Authentication

verifies

the

identity of a client

r

Authorization

decides

a

client s

level of access

to a

protected

resource

r

Integrity

ensures

that a

message

has not

been

modified

while

in

transit

r

Confidentiality

ensures

that

the

contents

of

a

message

are

kept secret

o

Auditing

maintains

records

to

hold clients

accountable to

their

actions

r

Nonrepudiation

allows

the

client

to

prove

that

the server

has received

a

previously

sent

message,

and

the

reverse

@ Copyright

IBN/l

corporation 2009

Figwe

12-2.

Review of basic security

terminology

w8555 /

V85552.0

Nofes,

Authentication

is

the

act

of

verifying the

identity asserted

by the client.

Normally,

a

security

token attached

to the

message

makes a

claim about

the client s

identity. Plaintext user

name

and

password

tokens,

X.509 certificates,

and

Kerberos tickets are all examples of

identity

claims.

Authorization is

the

process

of deciding

whether

a

client

has

access to a

protected

resource. This

process

also

determines

the

level

of access

that the server should

grant

the

client.

ln

most cases, the

authorization

decision

requires the client s

identity

to be

known

and

verified.

That is,

authorization

takes

place

after

authentication.

lntegrity,

also

known as

data

integrity,

makes

sure

that a

message is not

altered

or

tampered

while it

travels

between

the

client and

the server.

Digital signatures and

hash

codes can

prove

whether a

message

has been

modified

in

transit.

Confidentiality

ensures that

only authorized

parties

have

access to

protected

resources.

The

effect of confidentiality

is

to

keep

private

data or

resources

secret.

This

quality

is

often

implemented

through

the

encryption

of data,

where only authorized

parties

have

the

means

of

making

obscured

data

into

legible information.

@

Copyright

IBM Corp.

2009

Unit 12.

XML and Web services security overview

Course

materials may

not be

reproduced

in

whole

or

n

part

without the

prior

written

permisson

of

lBM.

12-3

El color azul de

la

impresin

garantiza

la autenticidad cle este documento

@ Copyrght


7/314

mrng

o

o

o

c

i

Auditing

is

the

process

of

maintaining

irrefutable

records for the

purpose

of

holding

clients

accountable to their actions. Signed

security

logs

provide

one

way

to audit a security

system.

The

concept of

nonrepudiation

is

tied closely

to auditing.

lt

is

the

ability of

one

party

of

the communication to

prove

that the other

party

has

received its message.

Nonrepudiation is

often split

into

two

concepts:

nonrepudiation of origin

proves

that

one

party has

sent a

message,

while

nonrepudiation

of

receipt proves that

one

party

has

received

a

message.

Nonrepudiation

is

enforced by

verifying the digital

signature

and the expiration date on the

message.

12-4

Accelerate, Secure and

Integrate with DataPower

@

Copyright

IBM

Corpj

2009

Course

materials may

not

be

reproduced

in whole

or

in

part

without

the

pror

written

permission

of

lBM.

El

color azul

de

la inrpresn

arantiza

a autentcidad

de

este

docLtronto

@

Copyt

ight


8/314

IBM Training

Student

Notebook

Web

servces

security

.

Web services

security

(WS-Security) provides a standard,

platform-independent

way for specifying

message-level

security

information

.

Flexible set

of

mechanisms

for

using a

range of security

protocols:

-

Does

not

define

a set of

security

protocols

-

Provides

end-to-end

security

Security context

Security context

\-

.J

I

I

I

I

I

I

\-

,7

Secu context

O

Copyrght

IBM Corporation 2009

Requester

lntermediate

node

Figure

12-3.

Web services security

w8555 /

V85552.0

Notes:

WS-Security does

not

describe specific

security

protocols.

This

model

can use

different

security

mechanisms, and

can be

configured

to

match

the

requirements of

new ones

as

they

are

developed.

By

separating the security

constraints

from

the

actual

implementation,

developers can

change security technologies

without needing to adopt another

Web

services secu

rity

specif

ication.

Each arrow between two

boxes shows a

point-to-point

security context.

Transport

level

security, such

as

SSL/TLS,

provides

a security context

that

persists

only

from

one

intermediate node

to another.

The

curved

line

that spans

multiple

boxes

is

an example of end-to-end

security.

This

security context

is

provided

by

WS-Security.

WS-Security

provides

message-level

security. SSLLS secures

the entire

HTTP request.

',

s

.Q

'-o

/.

.\ce-,

@ p.a*

{d

oQ

t e'rrscq-

'

@

Copyright

IBM

Corp. 2009

Unit

12. XML

and Web services security

overview

Course materals

may not be

reproduced

in

whole

or

in

pa1

wthout

the

prior

written

permission

of

lBM.

12-5

E coor

azu dc

la impresn

garantiza

la aLrtcnticidad de este clocunenlo

@

Copyriqht


9/314

rirg

Components

of

WS-Security

.

Associates

security

tokens with a

message

-

Username token

profile

sscio,/ca.,\fu

6w

-

X.509

token

profile

-

Kerberos

token

profile

-

SAML token

profile:

Security

Assertion Markup Language

-

REL token

profile:

Rights

Expression Language

.

Confidentiality

(XML

encryption)

l-

',fs....

-

Process for encrypting

data

and

representing

the

result

in

XML

'

lntegrity

(XML

signature) e$t

$rrr nc-

,

-

Digitally

sign

the

SOAP

XML

document,

providing

integrity and

signer

authentication

.

XML canonicalization

-

Normalizes XML document

-

Ensures two semantically

equivalent

XML

documents contain

the

same octet stream

o

o

a

o

o

o

c

l'

t^'

C

f-

(-

(t-

l-

('

(

('

(

(

(

(

(

(

(

(

I

(

(

(

i

(

(

(

(

O Copyright

IBM

Corporation 2009

Figure

12-4.

Components of

WS-Security

w8555 / V85552.0

Notes:

An XML

digital

signature

is

based

on the

W3C

recommendation

specification

for

XML-signature

syntax and

processing.

See

http://www.w3.org/TR/xmldsig-corei

XML

encryption

is based on the

W3C

recommendation for XML

encryption

syntax and

processi

ng.

See

http

://www.w3.

org/TR/xm

lenc-co

rel

The

security token

profiles

listed

are

for WS-Security 1.1.

For

links

to

the

list of

specification,

see

http :i/www.

o

as

i

s-ope

n

.

o

rgls

pecs/i

ndex.

ph

p#wssv

1 .

0

12-6 Accelerate,

Secure

and Integrate

with DataPower @

Copyright IBM

Gorp.

2009

Course

materials

may

not

be

reproduced in whole

or

in

part

wthout

the

prior

written

permission

of lBM.

El

color

azul

de la

impresln

garantza

la

auienticidad de

este

documento

O Copyright


10/314

IBN{ Trainirg

Student Notebook

Specifying

security

in

SOAP

messages

.

Attach

security-related information

to

SOAP messages

in

the

header

element

< --

SOAP

message body here

@ Copyright lBlV Corporaton 2009

Figure

12-5.

Specifying security

in

SOAP

messages

w8555 /

v85552.0

Nofes.'

The

actor

and mustUnderstand are special attributes

defined

by

the SOAP specification

The actor attribute contains a URL

of

the targeted

recipient for

the SOAP

header. The

mustUnderstand

attribute

is

used to specify that the tags

in

the

header must

be

understood; otherwise,

a

fault

is

thrown.

@

Copyright

IBM

Corp. 2009

Unit

12.

XML and

Web

services security overview

Course

materials may

not be

reproduced in whole or n

part

without the

prior

written

permission

of

lBM.

12-7

E co or rzLr cle a

rrrresi r

ga

a|tili

lUie|lio

clrd

cle

r;sict

cloc;urncnkt

O Copyr

gli


11/314

oirg

o

a

o

c

fi

o

l-

(

f

(

t

t-

(

(

(

(

(

{

(

(

Scenario

1:

Ensure

confidentiality

with XML

encryption

.

Keep messages

secret

using XML encryption

-

Encrypt with the

recipient s certificate: only the recipient can

decrypt

with associated

private

key

-

XML

encryption

specification

does not describe

how

to

create

exchange

keys

.

XML encryption

supports:

-

Message encryption at

different

levels of

granularity

.

From a single element

value to

a tree of

XML

elements

-

Secure

message exchange

between more than two

parties:

.

A message

may

pass

through

intermediate handlers

that

read

only the

parts

of the message

relevant

to them

@ Copyrght lBlV

Corporation 2009

Figure

12-6.

Scenario

1: Ensure

confidentiality

with

XML encryption

w8555

/ V85552.0

Notes:

By

encrypting

message

content,

the

privacy

of the content becomes

decoupled

from

the

transport mechanism.

For

example,

messages

sent

over an SSL connection

are

encrypted.

They

are

thus

are

provided

some

degree of

privacy,

but

no

further

privacy

is

provided

once

the message exits the SSL connection.

By

encrypting the content

of

the

message, the

message

can travel

across transport

boundaries, such

as HTTP and

WebSphere

MQ,

and

remain

private.

The ,

,

and

elements

cannot

be

encrypted.

12-B

Accelerate,

Secure and

lntegrate

with

DataPower

@

Copyright

IBM

Corp. 2009

Course

materials may

not be reproduced

in

whole or in

part

without the

prior

written

permission

of lBM.

(

(

I

(

(

El

color

azul

de la

impresin

garantiza

la

autenticidad

de este documento

O Copyright


12/314

IBM

Trainirg

Student Notebook

DataPower

support for XML

encryption

'

Applies XML encryption

to a

message

by

defining a document

processing

rule

containing:

-

Encrypt

action: Performs full

or

field-level

message

encryption

-

Decrypt

action: Performs full

or

field-level

message

decryption

.

Acts

as

clientto encrypt

a

message

sent

to

the server

@

Encrypt

.

Acts

as

server to decrypt

a

message

sent

by

the client

&

Decrypt

O Copyrght IBM Corporation

2009

aintext

I

XML

message

Plaintext

XML

message

Figure

12-7. DataPower

support for XML encryption

Nofes;

w8555

/

V85552.0

@

Copyright

IBM

Corp.

2009

Unt

12.

XML

and

Web

services security

overview

Course

materials

may not be reproduced in

whole

or

in

part

without

the

prior

written

permission

of

lBM.

12-9

El

color

azrl

cle a

inrpresn

gar;rntza

a alllontioiciacl

de csle

docuncrlr.r

G)

Coryriqlrt


13/314

ning

a-

Encrypt

action

.

The

Encrypt

action

performs

full or field-level encryption

-

Envelope method

.

Controls

placement

of

generated

security elements

-

Message Type

.

Style used to encrypt

messages

-

Message

and

Attachment

Handling

.

Encrypt

message,

attachment, or

both

-

Use Dynamically

Gonfigured

Recipient

Certificate

.

Uses certificate

in

previous

Verify

action,

if it

exists

-

One Ephemeral Key

.

Causes

all encryption in

this step to

use

the same

ephemeral

key

-

Recipient Certificate

.

The certificate used to

perform

encryption

O

tn.rypt

@

Copyrght lBNl Corporation

2009

Envelope Hethod

Hssage Typc

Asynchronous

llersage

and

ttchment

Handling

Encryption Key Type

Recpent CertfiEate

W9Serurity

Version

Us

DynamcllV

con{iqured

Recipent

Certificate

f-)WC5e

Encryptin

Sstandard

XML En(4,3tin

#dvnced

*

$soP

ttessage

$Raw

Xl lL

Docurnt

Qselected

Elements

(Field-Level)

f.Advanced

*

Qcn$cff

$anQcflSave

o

o

o

ft

o

o

c

l-

C

C

C'

C

r-

r-

('

(

(

(

(

(

,,

(

i

(

I

One Ephemeral Key

Qcncfisave

l.lse

Figure

12-8.

Encrypt action

w8555

/

V85552.0

Notes:

An

ephemeral

key is

a

key

that

is

generated

each

time

key

negotiation

occurs.

The DataPower device supports the

following

encryption

schemas:

.

WSSec

encryption

(OASIS)

standard

puts

the

signature and

key information

in

the

SOAP

header

.

Standard

XML

encryption

(W3C) puts

the

signature and

key

information in the

body of

message

The WS-Security standard

puts

the

signature and

key information

in

the

WS-Security

header

of

the SOAP

message.

This

standard

adds

no

elements

to the body of the message

and

therefore

does

not

violate the underlying

schema.

Standard XML encryption

was originally

designed

to

handle

any

XML message

including

those not formatted to the SOAP specification.

lt

puts

the signature and

key information

in

the

body

of the

message,

thus

adding additional

elements

to the

body of the

message.

The DataPower

SOA appliance

supports

both methods of

encryption.

The appliance

can

use

either

standard

for

full

message or

partial

encryption.

12-10

Accelerate,

Secure and

Integrate

with

DataPower

@ Copytight IBM Corp. 2009

Course

materials may

not

be

reproduced

in whole or

in

part

without

the

prior

written

permission

of

lBM.

El

color

azul

de

la

impresin

garantlza

la autenticldad

de

esle documento

O Copyright


14/314

IBM

Training

Student

Notebook

The

following

message

types are supported:

.

SOAP

message:

An

encrypted SOAP

document

.

Raw XML

document:

An

encrypted

XML

document

(it

cannot

be used

in

conjunction

with

WSSec

encryption)

.

Selected

elements

(field-level):

A

partially

encrypted SOAP document

The

following

options are

located

in

the

Message

and

Attachment

Handling

context

menu:

.

Attachments

only:

Only

the

attachments of

the

message

are encrypted.

.

Message

only:

Only the

message

(root

parl)

is

encrypted.

.

Message

and

attachments: The message

(root part)

and attachments

are encrypted.

@

Copyright

IBM

Corp. 2009

Unit

12. XML and

Web

services

security

overview

12-11

Course materials may not be reproduced

in whole or in

part

without

the

prior

written

permission

of

lBM.

El

color azul de la impresn

garantiza

la

autenLc

cjacl cle cste

doculnenlo

@ Copyt

glrl


15/314

ning

-

r

-o

Decrypt action

.

The

Decrypt

action

performs

full or

field-level

decryption

-

Message Type

Specifies how to decrypt the

message

-

Decrypt Key

Private key object

used

to

perform decryption

Basc

dvan


16/314

IBM

Trainirg

Student

Notebook

Field-level

encryption and

decryption

.

Performs

field-level

encryption and decryption

on

messages

-

Under

Message Type,

select

the Selected

Elements

(Field-Level)

radio

button

.

Create

a

Document

Crypto Map with an

XPath

expression of

the

fields

to encrypt

or, dec

tsu*a

f?c^l(^

c,,r

-

cbk

q

@

Copyright

IBM Corporaton

2009

+

ame DCl

ocument

Crypto ilap

Nessage Type

(Field-Levei)

rnnt

$

selected

$

rntire

dvanceC

l {loca

I

-

na me{

X

='

5'r'gl-p'

li

*

ll

oca

l-

name0

-'

gsy'l/+llosal-name[)

='findByNa

m e'll*{laca

l-nam

e0

:'Encrypted

at'l

x

pi'

i

[EGll

:

L,,:,:,

;

Exoot

I

vi.,ff

Loo

|

'r'ie,r

status

I

Help

Q

enabf

ed

fi

Cisabled

luci'

*

*

Doctenrenl

CrypTa

l4ap

:

lani

'tn

Expre;sion

dmin State

Commnts,

B:eraticn

Figure

12-10.

Field-level

encryption and decryption

wBsss

/

v85552.0

lVofes;

The XPath

expression can be created

from

an XML file

by

selecting the

elements to

encrypt

or decrypt.

The XPath

expression

for

field-level

decryption

is

different

from

the

XPath

expression

for

encrypting

the

same

field.

This

sounds incorrect,

but consider the

following.

Encryption

occurs on an element

in

the original message, for

example,

.

When

it is

time to decrypt, the

field is no longer

known

as

,

but as

something

else,

such

as

.

Thus,

the

XPath

expression

to

get

to the

apparently

identical

element will differ depending on whether

you

are encrypting

the

original field

or

decrypting

the encrypted field.

@

Copyright

IBM Corp.

2009

Unit 12.

XML

and Web

services

security

overview 12-13

Course

materials

may

not

be

reproduced in

whole

or

in

part

without

the

prior

written

permission

of

lBM.

El

color

azul

de la

impresin

garantza

la autcnticiciad

de este docunrento

O

Copyright


17/314

rirg

a^f,

98

?^

o

o

o

o

t\

o

c

(-

C

(-

{'

f-

a

('

St

Vr.e

cI

t\

iC-t -

\t

@

Copyright

lBtV

Corporaton

2OOg

Figure

l3-5.

How

to define

an access

control

policy

(l

of

2)

Unit

13.

Authentication,

authorization

Course

materials

may

not

be

reproduced

in

whole

or

in

part

without

the

prior

written permission

of

lBM.

w8555

/ V85552.0

Notes:

The

access

control policy

steps

relate

directly

to

the

processing

stages

within

the

AAA

framework

ln

the

first

step,

the

policy

definei

how

the framework

retrieves

information

about

the

client s

identity.

The

framework

can

treat

the

requested

URL,

the

client

lp

address,

the

HTTP

header,

or

any

part

of

the

message

as

a

client

identifier.

Once

extracted,

the

second

step

describes

how

to verify

th

claimed

identity

stored

in

the

message

lf

the

authorization

method (which

is

described

on

the

next

slide)

expects

a

different

client

identifier, the policy can apply

a

custom

style

sheet to convert

the

authentication

credentials.

,

and

auditing

(AAA)

1g-T

El

color

azur

de

ra

irrpresin

garantiza

la

autenticidacl

cje

este

crocLrncnto

O

Coryright

XML

message

ldentity

@

Copyright

tBM

Corp.

2009


37/314

nitg

How

to

define

an

access

control

poltcy

(2

of

2l

4.

Define resource extraction

methods

5.

Map

requested

resources

(optional)

6.

Define

the

authorization

method


38/314

IBM

Trainirg

Student

Notebook

Access

control

policy

processing

Allow

Allow

Post

Map

credentials

i------M;;

I

I

esource

r

I

O

Copyright


Deny

Deny

Post

I

I

r

Extract resource

Treat as unauthenticated client

ccept

client identity

Extract identity

Authenticate

Generate error

to

rule

eturn to rule

Treat as unauthorized client

llow access

to

resource

Authorize

Figure

13-7.

Access

control

policy

processing

wB55s

/

VBsss2.0

Nofes.

The

numbers correspond

to the access

control

policy

steps detailed

on the

previous

two

slides. Keep

in

mind

that

the output

message

is returned

to

the

processing

rule, not

back to

the

actual

client

itself.

Similarly,

errors

generated

from

a

AAA

action

can

be suppressed or

handled

by an

On

Error

action or

an error

rule.

The

only

part

of the

postprocessing

step that occurs

when

authorization

fails is

the

incrementation

of

the authorization

failures

counter

(if

one

exists).

Within

the

postprocessing

step,

monitors

keep

track

of the requests.

@ Copyright IBM Corp. 2009

Unt

13.

Authentication, authorization,

and

auditing

(AAA)

Course

materials

may not be

reproduced

in

whole

or in

part

wthout

the

prior

written

permission

of lBM.

13-9

El

color azul de

la

impresif

garatiza

la

autenticidad de este

docunrer.to

@ Copyri.cJht


39/314

ning

Scenario

1: Authorize authenticated clients

.

Create

an

access

control

policy

that

handles client SOAP Web

service

requests with the following conditions.

-

The client

communicates

to the

DataPower SOA appliance over a

Secure Sockets

Layer

(SSL)

connection

-

A WS-Security UsernameToken

element holds the

requesting

client

identity

-

Verifies the claimed

identity

of

the

client against a

list

stored on

the

DataPower SOA appliance

-

The

requested resource

is

the Web service operation

-

Allows

any

authenticated

client access

to

the

Web service

operation

-)

o

o

o

o

o

c

C

c

(

r

(-

(

(

(

(

(

(

(

(

(

(

(

I

i

I

(

(

I

(

(.

I

(

@

Copyright IBM Corporation 2009

Figure

1

3-8.

Scenario

1 :

Authorze authenticated

clients

w8555

/

V85552.0

lVofes.

ln this

scenario, the

client

includes a

WS-Security

username token

with

a

password

or

password

digest

as a

proof

of

identity. As a best

practice,

clients should send

plaintext

tokens such as the

WS-Security

username

token,

within

a

secure

channel such

as an SSL

connection.

The access control

policy

on

the

DataPower SOA appliance

verifies

the

user name

and

password

against

a built-in user

list. lt

assumes

that

all

authenticated users

have

full

access

to

any resource protected

by

the

policy.

tt.

Srz

,^.(*-

e)/,

t


40/314

IBM

Training

Student

Notebook

Scenario

l:

Sample

SOAP

request message


41/314

ning

o

Scenario

1: Identify

the

client

1.

Create a new AAA

policy object on the

DataPower SOA

appliance

2.

Extract

the

client's

identity

using the

Password-carrying

UsernameToken Element

from

WS-Security Header

option

3.

For the authentication method,

Use DataPower

A/fuA

Info

File

Specify

the

name of

the

A/avA

information file

in

the URL field

4.

Leave

the

identity

mapping method

at none

oQ'-c6

*'

b

o

o

o

t

a

f'l

o

l'

('

(.'

(

(

{

i

(

(

@ Copyright IBM

corporation

2009

@f

Passwerd

-c

arrying

lJ

serna

m eTo ken El

ement f

i'a m W

S

-Secu

rit'y H

ea

d

er

I

Derived-key U;ernameToken

Element

from

'/fS-Security

Header

J

7ui

narq

Eec,trityTole n

El

enr

ent

f

rorn'*V

S

-

gecu

rit'y

H ead

er

[

+/3-5ecu

reCcn,o,ersatio Identif

ier

l_...1

\il5-

lrust

e

r Suppftf

n

lakefl

F

nrrf

.4.uthentiratien Header

Custom

Template

ffPass

ldentity

Token

ts the

uthorize Step

QXetri

eve

SAlcl L A.sserti o

ns orrespon

d

in

g

tr

0une

fiuse

SUse

fiuse

an

Established T/S-Securetonversatiol

Hethod

specified

trADIUS

Server

ceificte frem

inarySecu

DataPower

AX

Info

Fil

UEL

E

*

pload...

"A-Infn,yml

Figure 1 3-10.

Scenario

1 : ldentify

the client

w8555

/

V85s52.0

Notes:

Nc

\r,q5

h:--?11'^g

X4

dc."^o9

f,'rr

a,'

\-rnr^r\-s

"t"tk"->.

13-12 Accelerate,

Secure

and

Integrate with

DataPower

@ Copyright IBM Corpr 2009

Course materials

may not be reproduced in

whole

or in

part

without

the

prior

written

permission

of

lBM.

El

color azul de la mpresin

garantiza

la

autentlcidad

de este documento

O Copyright


42/314

IBM Trainirg

Student

Notebook

Scenario 1: Authorize

access

to

resources

5.

Select

Local

name

of

request element as

the

resource

extraction rnethod

-

The

name of

the

child

element

in

the

SOAP

body

of

the

request is the

request

element

name

6.

Leave

the

resource

7.

For the authorization method,

allow any request

from

an

authenticated

client to

proceed

@ Copyright lBN4 Corporaton 2009

'

A.lnfo

File

#qtlo*

Any

A.uthenticate.d

lient

CAlway

Allow

Check

for

Memer.ship

in

an LAP

rrrup

QContact

(learrust

5rver

fi

tentact

Neteg rity

EiteMinder

SContact

blix

5e

rqer

flfontact

Tivoli Access

toanager

Q-

Methcd

f]

UAI

-qent

te ?ac*

End

unl

Sent

by Client

Uet

o

Taplevel

Element in

the

l*lessage

ffi

tu:al

lulame

af

Rquest

Elemenf

f

c:

nrrc

peratiorr

icETlFrlsT)

I

xaath

Ex:ression

I

F

r r:

ce-"-ing

l'4 eta

d ata

#

Resource ldentificatior

Hethod"s

v

lcne #ethod

Fgure

1 3-1 1.

Scenario

1 : Authorize access

to

resources

Notes:

wB5s5

/

V855s2.0

@

Copyright IBM

Corp.

2009 Unit 13. Authentication, authorization,

and

auditing

(AAA)

13-13

Course

materials may not

be

reproduced in whole

or

in

part

without

the

prior

written

permission

of

lBM.

El

color azul de a irnpresn

garantiza

la

auteticidad de

este

docunrento

@

CoJrytglrt


43/314

ning

Scenario

2: Security

token conversion

.

Create an access control policy

that

handles

client

SOAP Web

service

requests with the

following

conditions:

-

The client communicates

to

the

DataPower

SOA appliance over

a

Secure Sockets

Layer

(SSL)

connection

-

The

HTTP BASIC-AUTH

header information holds the identity

of

the

requesting client

-

Generates a

WS-Security UsernameToken element

corresponding to

the HTTP BASIC-AUTH

header

-

Defers the authentication and authorization tasks to

the

back-end

Web service

a

o

o

o

o

o

o

o

c

c

C

l

(-

(-

I'

(

(

('

(

(

(

(

(

(

(

(

(

(

(

(

(

(

(

(

(

(

(.

(

(

(

I

@ copyright


Figure 1

3-12. Scenario

2: Security

token

conversion

w8555

/

V85552.0

Nofes;

HTTP BASIC-AUTH

refers to

the

basic authentication scheme.

Refer

to

the

following

slide

for

an

example

of

an

HTTP request message

with

a basic authentication

header.

r

Z

e

;i=4.l5cc"rr-sa^-

Q

,t':

(n-

a'.cuLeE:zes'

13-14 Accelerate,

Secure and

Integrate

with

DataPower @ Copyright

IBM

Corp.

2009

Course materials

may not be reproduced

in

whole or

in

part

without

the

prior

written

permission

of

lBM.

El

color azul de

la impresin

gaanliza

la autenticidad de este

documento

@ Copyright


44/314

IBM

Training

Gr

Stu

Scenario

2:

Sample

HTTP

request

message

POST

/gastAddress/servces/addressSearch

HTTP

/

t.L

Host: www.

example.

com

Content-tLpe: text/xml;

charset=utf

-8

Content-lengthz

237

Authorization

:

Basic T3phaXISU2hlaltoTk,fha2U=


45/314

nmg

Scenario

2:

Identify the

client

&

O_*,o.k

.W

a,

o

a

o

o

o

o

('

t-

('

1.

Create

a

new

AAA

policy otrject

olt

the

DataPower SOA

appliance

2.

Extract the

client's

identity using

the

HTTP's

Authentication

header

option

r

The

value within the

Authorization

HTTP

header

represents

the

HTTP

authentication

header

3. For the

authentication

method, specify

Pass

ldentity

Token to the

Authorize

Step

4. Leave

the identity mapping

method at

none

QC*ntact

Tivsli

,4ccess

Flanager

QEuetam

Template

Browser Atifact

Identi?y Taken to the Authoriee

Step

S..| IL eertiona

Corresponding

tc

a

SAIL

@

Copyright


p

tiTP' x

gutfrsrtietisn

l"lder

f

F*wwnrd-onrryin

Urarncm*Taf


46/314

IBM

Training

Student Notebook

Scenario

2:

Authonze

access

to

resources

5.

Select

Local

name

of

request

element

as

the resource

extraction

method

-

The name

of

the

child

element

in

the

SOAP

body

of

the request is

the

request

element

name

6.

Leave the resource

mapping

method at none

7.

Set the

authorization

method to Always

Allow

requests

B.

ln the

post

processing

step,

Add Ws-Security

Username

Token.

,4

Qu

Hethod

J*^b,

e_

@ Copyrght IBM Corporation 2009

a.,

|1

URL

Sent

to

Back

End

l

URL

Sent

by

Client

lI

URI

of

Toplevel Element

in

the Message

fi

Local

Name

of Request Element

f

HTTP operation

(cer/Posr)

l|

f-

XPath Expression

1.4|;

e

fl

processing

Metadata

,r_.r*9

,i

-

q"rS:

Rsource ldentification Methods

QonQoff

w\urw9

s12

ol


47/314

ning

o

Scenario

3:

Multiple identity extraction

methods

.

Create an

access control

policy

that

handles client SOAP

Web

service

requests with

the following conditions:

-

Uses either

a

WS-Security

UsernameToken

element or a

BinarySecurityToken element

from

the

WS-Security

header

to

determine

the client s identity

-

Verifies the

identity

of

the client

-

The

requested resource

is

the Web

seruice operation

-

Allows

any

authenticated

client access to

the Web service operation

@

Copyright IBM Corporation

2009

;

o

o

o

o

o

o

f

c

c

c

c

1..

(

C

(

(

(

(

(

(

(

(

(

(

(

(

(

(

(

(

(

(

(

(

(

Figure

13-16. Scenario

3:

Multiple identity extraction

methods

w8555

/ V85552.0

Notes:

For identity

extraction

methods, the

policy

executes

all checked

methods. The

system

executes

the

methods

in

the order

presented

by the check box

list.

Afterwards, the system

concatenates all

identities

found

for

authentication.

This scheme allows different

clients to

use different

identification methods.

However,

if

a client

includes

more

than

one

identifier in

the

message,

both

identifiers must

pass

the

authentication stage.

13-18 Accelerate,

Secure

and Integrate

with DataPower

@

Copyright

IBM

Corp.

2009

Course

materals

may not

be reproduced

in

whole

or

in

part

without

the

prior

written

permission

of

lBM.

El

color azul

de la impresin

garantiza

la

autentrcidad de

este documento

@

Copyright


48/314

IBM

Trainirg

Student

Notebook

Scenario

3:

ldentify

the

client

1.

Create

a new AAA

policy

object

on the

DataPower

SOA

appliance

2. Extract

the

client's

identity

from the

UserName

element

or a BinarySecurityToken

-

Separate WS-Security

token

profiles

describe

the structure

of

the

UsernameToken

and

the

BinarySecurityToken

3.

For the

authentication

method,

specify

Bind to

Specified

LDAP

Server

-

The

LDAP

directory

server

provides

an

external

list

of

authenticated

users

4.

Leave

the

identity

mapping

method

at none

@

Copyrght

IBM Corporton 2009

fi

Password-carrying lJsernameToken

Element

from

WS-security

Header

l-

Derived-key

UsernameToken

Element

from

WS-Security

Header

ff

BinarySecurityToken

Element

from

WS-security

Header

f

WS-SecureCo

nversati

on

Identifier

l-

WS-Trust

Base

or

Supporting

Token

l-

Kerberos

AP-REQ from

WS-Security

Header

Kerberos

AP-REQ

from

SPNEGO

Token

er

n

He

fi,Use

DataForver

AAA Info File

lF

Bind

to

Specified

LDAP

Server

li

Contact Tivoli

AccesE

l lanager

{-,

Contact

Netegrity

SiteMinder

fl

l.Jse

specified

RADIUS

Server

Hethod

none

'*.

Hethod

Figure

13-17.

Scenario

3:

ldentify

the

client

Notes:

w8555

/

V85552.0

@

Copyright IBM

Corp.

2009

Unit

13.

Authentcation,

authorizaton,

and

auditing

(AAA)

l3-19

Course

materials

may not

be

reproduced

in whole

or

in

part

without

the

prior

written

permission

of lBM.

E

color

azul de la rmpresin

earattiza

la

autentio

cjacl dc

este clocunrento

CO

Cottyri(lr1


49/314

ning

Scenario

3:

Auth orize

access

to

resources

5.

Select

Local

name of

request

element

as the

resource extraction

method

-

The

name

of

the child

element

in

the SOAP

body

of

the

request

is

the

request element

name

6.

Leave the

resource

mapping

method

at

none

7. For

the

authorization

method, allow

any

request

from

an

authenticated

client

to

proceed

C,A,qq

Info

File

ffi,Ello,*

Any .Authenticted Cl ient

QAlways

Allow

Qcheck

fsr

Membership

in

an

LDAF

Gr

fiContaat

ClearTrust Server

O Copyright IBM Corporaton

2009

Iunl

Sent

to

Back-End

nueu

gent

by

client

nunl of Toplaval Element

in the lulessage

Elscal

Name f Reque--


50/314

IBM

Training

Student

Notebook

Internal

access control resources

.

Authentication

and authorization

can

be performed on the

DataPower

box

using:

-

AAA

file: XML file containing validation

information

for

the AAA

steps

(authenticate,

authorize, map credentials, map

resource)

-

LTPA: Token

type used

by the

IBM

WebSphere

Application

Server

and

Lotus

Domino

products

-

Validation

credential object:

List

of certificates

used to validate

the

incoming

digital signature

AAAInfo.xm

LTPA

Validation

credential

Client

Server

d

f-

-f

F

ftd

@ Copyright IBM Corporaton

2009

Figure

13-19.

lnternal access

control

resources

w8555

/ V85552.0

lVofes.

The validation

credential

object

references

a

list

of

certificates

on

the

appliance

that

will

validate

the incoming

digital signature. This

object

is

also

used

when

configuring

client-side

SSL.

@

Copyright IBM

Corp. 2009

Unit

13.

Authentcaton,

authorization, and

audtng

(AAA)

13-21

Course materiafs may

not

be

reproduced

in

whole

or in

part

without the

prior

wrtten

permission

of lBM.

El color

azul

de la

impresin

garantiza

la

autenticidad

de este ciocumento

@ Copyright


51/314

mng

o

AAAXML

file

.

The

AAA

XML file

is used to

validate the credentials

in a AAA

policy

-

Used

by

the following

AAA

steps:

.

Authenticate

.

Authorize

.

Map

credentials

.

Map resource

.

Useful

for

testing

of AAA

policy

when off-box

resources

not available

-

Use

in

production

to

maintain

small

list

of

AAA

credentials

.

For the

authenticate

or authorize

step

in

the

AAA

policy,

select Use

DataPows

AAA

Info

File

-

Select

an

existing XML

file

or create

a

new AAA file

?

O

a

a

o

o

G

c

(^t

f-

(-

(

lr

(

(

(

I

(

(

:

(

i

t

ataFswer

uq

Inf File

epecified

F.ADIUC

Seruer

QValidate

a

Kerbpros

AP-REQ

for the

Crrect

Server Principal

flvalidate

the Signer

Ceztificate

f*r a Bigitally Signed

r4essage.

QValidate

the 5 51

Ceifisete

from the

Connection

Peer

*

+

,1

URL

*

sretf

f f

FbuqJnfo-xml

@

Copyright


Figure

13-20.

AAA

XML

file

wB555 / V85552.0

Nofes,

The

DataPower

WebGUl

includes a set of

wizard

pages

that

make

it

easy to create

a

AAA

XML file.

13-22 Accelerate, Secure and

lntegrate

with

DataPower

@ Copyright

IBM

Corp.

2009

Course

materials may not be

reproduced

in

whole or

in

part

without the

pror

written

permission

of

lBM.

El

color

azul

de

la

irrpresin

garantiza

la autentcidad

de este documento

@ Copyright


52/314

IBM Training

Student

Notebook

Example

AAA

XML

file

Iocal z

/

/

/

xdaresslnfo.

xml

A.A

file to

validate

credentials for Address

users

Addres

sAd.min

pas

sword

AddressUser

o copyrght lB/ Corporaton 2009

Figure l3-21.

Example AAA XML file

w8555

/

V85552.0

Nofes.'

This AAA XML file

is

used

by the

Authenticate step

to

validate

the extracted identity.

The

incoming

identity should

have

a

user

name

of

AddressAdmin

and

password password.

@ Copyright

IBM Corp. 2009

Unit

13.

Authentication, authorization,

and auditing

(AAA)

13-23

Course materials may

not

be

reproduced

in whole

or

in

part

without the

prior

written

permission

of

lBM,

l

color

azul

de

la mpresin

garantiza

l

autelrticlclrcl

de este

doculIerto

(0

Copyr

clrt


53/314

ning

(9

Ccpz

e

.d

g

*

gou-;

, tb--.

V

7.rr)z

hc^cr

S:

^e-T

& rbr^^-

itr-r-rcnt L

3

* c>.

Lightweight

Third

Party Authentication

.

Lightweight

Third

Party

Authentication (LTPA)

is

a single

signon

(SSO)

credential

format for distributed,

multiple

application server

environments

,ru

-

LTPA

is

a

proprietary

token

type used by the

IBM WebSphere

Application Server and

Lotus Domino

products

.

The

purpose

of

LTPA

is

threefold:

-

Propagates

the

caller

identity through a unique

identifier

of

the

client

-

Establishes

a

trust

relationship between

two servers,

with

one as the

client and one as the server, through a signed token

-

Keeps the

information within

the token secret

by

signing

and

encrypting the

token

.

A

set of

key files must be uploaded

to

the

DataPower SOA appliance to

decrypt and validate the

digital signature

within the token

se2..tr

e-^\rc-

ooK.5c,.c^c

4

,^c^ie5c

[aot\-

s.r=-Q

\Je*

,

Q

a c-

8>


54/314

IBM

Training

sru

'

External

access

control resource

LDAP, SAML,

IBM

Tivoli,

RADIUS

K

Client

Server

'

Delegates

the

authentication

and authorization

task

to an

external

security system

'

The

authentication

and authorization

tasks

can

be delegated

to

the

same

system

or

to

separate

systems

-

For

example,

an LDAP

directory

keeps

track

of client

identities

while

IBM

Tivoli

Access

Manager

determines

whether

the

client

has

access

to

the specified

resource

-

The

map

credentials

and

map

resource

steps convert

the security

token

to

match

the

input

[:S]jj,r,g,g Hx:lf

authorization

step

Figure

13-23.

External

access control resource

w8555

/

V85552.0

Notes:

It is

also

possible

to

perform

authentication

and

authorization

on an IBM

Tivoli

Access

Manager

system.

Tivoli

Access

Manager

can

be configured

to

use its

own

user repository

for

authentication

instead

of

using

a separate,

external

Lightweight

Directory

Access

Protocol

(LDAP)

server.

The list

of external

access

controls

on

this slide is merely

an

example.

Consult

the

WebGUl

guide

for

a

full

list

of

security

products

and specifications

that

are supported.

@

Copyright

IBM

Corp.

2009

Unit

13.

Authentication,

authorization,

and

auditing

(AAA)

1g-2s

Course materials

may

not

be

reproduced

in

whole

or

in

part

wilhout

the

prior

written

permission

of lBM.

El color

azul de la

impresin

garaIiza

la

aulenticidad

de este

clocutretto

@ Copyright


55/314

mng

Lightweight

Drectory Access

Protocol

.

LDAP

provides

a

means of storing

and

retrieving information

about

people, groups,

or objects

on a centralized

X.500

or

LDAP directory

server.

.r.

:

-

X.500 enables

the information to

be organized and

queried,

using

LDAP,

from multiple

Web

servers

using a variety of attributes

-

LDAP reduces system

resources by

including only a

functional

subset

of

the

original

X.500 Directory Access

Protocol

(DAP)

.

A few

facts

about

LDAP:

-

An

LDAP directory

is a tree of

directory

entries

.

The

distinguished

name

(DN)

acts as

a

unique

identifier

for

entries

-

A bind

operation

authenticates

the client

by

sending

the client s

distinguished

name and

password

in cleartext

.

Use an SSL connection

to

keep

LDAP

queries

secret

l

a

a

o

o

o

O

fl

l

c

C

C

(

(

(

(

(

(

(

O

Copyright lBN4

Corporaton

2009

Figure

13-24.

Lightweight Directory Access

Protocol

Notes:

The next

presentation

discusses configuring

AAA

using

LDAP

wBs55

/

v85552.0

13-26

Accelerate, Secure

and

Integrate

with DataPower

@ Copyright

IBM Corp; 2009

Course

materials may not be

reproduced

in whole

or

in

part

without

the

prior

written

permission

of lBM.

El

color azul de la

impresin

garantiza

la autenticidad de esle documento

O

Copyriqht


56/314

IBM

Training

Student Notebook

Security Assertion

Markup Language

.

SAML provides

an

XMl-based

framework for exchanging

authentication,

authorization,

and attribute

assertions

between

the entities

-

This language

provides

a standard,

platform-neutral

way

for

exchanging

security information

between

a security system

and

an

application that trusts the

security system

-

Expands

the authentication

and authorization

trust model

from

existing systems

by allowing new systems

to

delegate

trust

management to other systems

-

lncludes

protocol

for

requesting

this

information

from

security

authorities

.

For

example,

SOAP

and

HTTP bindings

@ Copyright


Figure

13-25.

Security Assertion

Markup Language

w8555

/

V85552.0

lVofes.

Federated

security systems require

an

interoperable

way

of sending

security information

from

one

system

to another.

The

Security

Assertion

Markup

Language

(SAML)

has

been

designed

specifically for

this

purpose.

lt

is

analogous

to how

the SOAP

specification

defines

a messaging model

for

transferring

information

between Web

service clients

and

servers.

SAML

allows clients

or

intermediaries

to embed claims,

or assertions,

into

the

message

itself.

One

common

use

for

assertions

is

single signon:

after a security

server authenticates

a client,

a SAML

authentication statement

is

tagged to

the client s request.

Subsequent

systems

processing

the request need

only to trust the

assertion instead

of authenticating

the

client again.

@

Copyright

IBM Corp. 2009

Unit 13. Authenticaton,

authorizaton, and

auditing

(AAA)

Course materals may not

be

reproduced

in

whole

or

in

part

without

the

prior

written

permission

of lBM.

13-27

El

color azul de la impresin

garantiza

a autenticrdad

de este

docurrento

@ Copyrqht


57/314

ining

Types of SAML assertions

.

Three

main

types

of

XMl-based

SAML assertions

exist:

-

Authentication

assertions

represent

the identity of the specified

subject

verified

by

another

entity

-

Attribute assertions

represent any

attributes associated

with

the specified

subject

-

Authorization

decision

assertions

represent

whether

the specified

subject has been

granted

or denied

access to

a

specified

resource

.

ln addition,

the

HTTP binding

provides

a

non-XML

reference:

-

A SAML

artifact

embedded

in

the

URL

query

string

provides

a reference

to

an

actual

SAML

assertion

stored

in

a rgmotg site

@ copyrishr

rBN/

corporarion

200s

i; ;;;-

XML message

)

o

o

o

o

o

o

f

n

C

(-

o

e

('

(

(

(

(

(

(

(

{

(

Permission

XML message

XML

message

HTTP header

Figure

13-26.

Types of SAML

assertions

w8555

/ V85552.0

Notes:

ln

plain

terms,

here are some typical

statements

made

by

the three types of SAML

assertions:

.

Authentication statements:

l

am

Bob

Smith.

.

Attribute statement:

Bob

Smith

is

a

payroll

manager.

.

Authorization decision statement:

Payroll

managers

can execute the

Payroll

Update

Web service.

These

assertions

avoid

repeating the

same

checks

on the same

message

as

it

passes

through different

systems.

ln

addition,

assertion

statements

delegate

the

authentication

and authorization

task

to

a separate

server.

The last

point

describes

the

HTTP binding

for SAML.

Keep

in

mind

that

SAML is

not

only

used

for Web services.

For

example,

a

Web

application

server

might

want

to

verify

a

SAML

assertion

in

a single

signon

(SSO)

scenario.

Without even examining

the

HTTP request

message, the server extracts

and

dereferences

a SAML

assertion

just

from

the

URL

query

string.

13-28

Accelerate,

Secure

and

Integrate

with

DataPower

@

Copyright IBM Gorp.

2009

Course

materials

may not be

reproduced in

whole or in

part

wthout the

prior

wrtten

permission

of

IBM'

El color

azul

de

la impresin

garantiza

la autenticidad

de este documento

@

Copyright


58/314

IBM

Training

Student

Notebook

Scenario 4: Authonze

vald

SAML

assertions

.

Create an access

control

policy

that

handles client SOAP Web

service

requests with

the following

conditions:

-

A

SAML

authentication

assertion

holds

the

requesting

client identity

-

Accepts

the claimed

identity

of the client if

the

digital

signature

of the

SAML

assertion is

valid

-

The

requested resource

is defined

as

an attribute

in

the SAML

assertion

-

Allows

any

authenticated client with

a specific

SAML

attribute

access

to the Web

service operation

@

Copyrght IBM Corporation

2009

Figure

13-27. Scenario 4: Authorize valid

SAML assertions

wB55s

/

V85552.0

Notes:

ln

this example,

the

request message

contains a

SAML authentication

statement

and

a

SAML

attribute

statement.

The

authentication

statement

claims

that the

current requester

has

been verified in

a

previous processing

step. The

access

control

policy

accepts

this

claim

if

and

only

if

the digital signature used

to sign

the

claim

is

valid.

An

application-specific

SAML attribute describes

the

resource

requested

by

the

client.

The

policy

authorizes

the

request if

the

current

requester

is

an authorized

user.

@

Gopyright

IBM

Corp. 2009

Unit

13.

Authentication,

authorization,

and

auditing

(AAA)

t3-29

Course

materials

may

not

be reproduced

in

whole

or

in

part

wlthout

the

prior

written

permisson

of lBM.

Ei

color azul

de la impresrn garantiza

la

autenlicidad

de este

documento

@

Copyright


59/314

ining

Scenario

4:

SAML

authentication

statement

eldentifier>

urn: oasis:names: tc:

SML:1.0:

cml sender-vouches

sertion"

a

o

t

o

o

n

(^'

r'

'

t-'

(

@ Copyright

IBM Corporation

2009

Fgure l3-28.

Scenario

4: SAML authentication

statement

w8555

/ V85552.0

Nofes;

This is

an

example of a SAML

assertion

generated

in

the

post

processing

step

of an

access

control

policy.

The

conditions

element

defines a

window of time

in

which this statement

is

valid. This

time

limit reduces the

likelihood of

a

replay

attack.

Within

the authentication

statement,

the

subject

element describes

the

identity

of

the

client

through

a

name

identifier

element. The

subject

confrmation

element describes

which

party

backs

up

the

claim.

ln

this

example, the

message

sender

vouches for

the

validity

of this

claim.

It

is highly

recommended that

SAML assertons

be

digitally signed to

maintain the integrity

of the

claim.

13-30

Accelerate, Secure

and

lntegrate

with

DataPower

@ Copyright

IBM

Corp.

2009

Course

materials may not be reproduced

in

whole

or

in

part

wthout the

prior

written

permission

of

lBM.

El

color azul de

la irrpresin

garantiza

la

autenticidad

de este documento

@ Copyright


60/314

IBM

Training

Sudent

Notebook

Scenario

4=

SAML

attribute

statement

adnin

Query

@ Copyright

IBM

Corporation 2009

Figure

13-29.

Scenario

4:

SAML

attribute

statement

wB5s5

/

V855s2.0

Notes:

This is an example of a SAML

attribute statement,

holding


information.

Similar to

a

SAML

authentication statement,

the name

identifier element describes

the

subject

that

added

the

attribute.

The

attribute

element describes


information.

For

example, a SAML

attribute element

can encapsulate

fields from an

LDAP

directory

entry.

The

system can use

this additional information about

the

subject

to

make an authorization decision.

Again,

it

is highly

recommended that SAML

assertions be

digitally signed to

maintain

the

integrity

of

the claim.

@

Copyright

IBM

Corp.

2009 Unit

13.

Authentcation, authorization,

and

auditng

(AAA)

13-31

Course

materials may

not be

reproduced

n

whole or in

part

wthout the

prior

written

permsson

of

lBM.

E

color

azul

de

la impresin

garantrza

la

autenticidad

de

este docunrento

tO

Copyricht


61/314

ining

Scenario

4:

ldentify

the client

1.

Create

a

new AAA

policy object on the

DataPower SOA

appliance

2.

Extract

the

client s

identity using the

Name

from

SAML

authentication

assertion

option

3.

For the

authentication

@ie.ccept

a SA1L

Aseeion

rrth

a Valid

gignature

f,ccept

an LTFA token

QBind

tr

Specified L.F

gerver

QCntact

a

E1+ML

Server

for

a

5Af,4L

uthentication

o copyright

IBM

corporation

2009

Method

a

o

o

o

o

o

o

c

C

t\

e

t

(

(

(

(

(

(

(

(

(

method, select Accept

a SAML

Assertion

with a

Valid

Signature

SAML ssnture

talidation credentiak

l|;;.;;

J-J

-

Specify

the validation credential

for

the SAML

signature

4.

Leave

the identity

mapping method at none

fi

Name

from

SAML

attribute

assertion

|7

Name

from

SAML uthentication

assedion

F

SAML ttifact

l

Client

IP

ddress

I

Subject

DN

from

certificate in

the

message s

signature

Identification Hethod

Figure 13-30. Scenario

4:

ldentify the

client

w8555

/ V85552.0

Nofes,

The

access

control

policy

needs

the

validation

credential

in

order to

verify

the signature of

the SAML assertion.

13-32

Accelerate, Secure and lntegrate

with DataPower

@ Copyright

IBM

Corp.

2009

Course

materials may

not

be

reproduced

in

whole or

in

part

without the

prior

written

permission

of

lBM.

El

coor

azul de la impresin

garal,liza

a autenticdad

de

este docurnento

O

Copyright


62/314

IBM

Training

Student

Notebook

Scenario

4:

Authorize

access

to

resources

5.

Select

Local

name

of

request

element

as

the

resource

extraction

method

-

The name

of

the

child

element

in

the

SOAP

body

of the

request is the

request

element

name

6.

For

the

authorization

method,

Use

SAML

Attributes from

Authentication

-

Set the

SAML attribute

matchng

type

as

Must

match

at

least

one name

and

value

7.

Select

SAML

Attributes

from

the

authentication

method

page

@ Copyright

lBl\4

Corporation

2009

Resource

Identification

Methods

f

URL

sent to

back

end

l:

URL

sent

by

client

f

URI of

toplevel

element

in

the

message

l7

Local

name

of

request

element

f

HTTP operation

(GET/POST)

l-

XPath

expression

${

f

Generate

a

3AtdL

.Autharization

eue.r'y

f

Generate

sfttl

.tiribue

euer

ff'

Use

5"ltlL

ltributes

from

"4uthentication

TyBe

Flethod

$ell-tralues

*il

Sany-value

nv

Sxeath

SAML

4ttributes

e".l

I

n"*t

I

advonced

I

c.n*r

I

Figure 13-31.

Scenario 4:

Authorize

access to resources

w8555

/

V85552.0

Nofes.'

When

authorizing requests

based

on SAML

attributes,

you

must

specify

one

or more

expected

attributes

in

a

separate

page.

The

following

slide

describes

how

to

enter in

the list

of expected

SAML

attributes.

@ Copyright

IBM

Corp. 2009

Unit

13.

Authentication,

authorization,

and

auditing

(AAA)

l3-33

Course materals

may not

be

reproduced

in whole

or in

part

wthout

the

prior

written permission

of lBM.

El

color

azul

de la tmpresrn galantiza

la

autenlcicjacl

cle este

clocrllcnto

O

Copyrl lht


63

accelerate secure and integrate with ibm websphere datapower soa appliances - vol 2

Documents