Post on 08-Apr-2018
transcript
8/7/2019 WS SOA Security
1/66
Securing Web Services(WS-Security, SAML)8Gustavo Alonso
Computer Science DepartmentSwiss Federal Institute of Technology (ETHZ)alonso@inf.ethz.chhttp://www.iks.inf.ethz.ch/
8/7/2019 WS SOA Security
2/66
Web Services Security Standards
8/7/2019 WS SOA Security
3/66
Gustavo Alonso, D-INFK. ETH Zurich 3
Security Standards Overview
TCP/IP
HTTP, JMS, SMTPTLS/SSL
HTTPST r ans por t
XML
SOAPXML Encryption
XML Signature
WS-SecurityX ML Mes s agi ng
SAML, XACML, WS-Trust, High Level
8/7/2019 WS SOA Security
4/66
Gustavo Alonso, D-INFK. ETH Zurich 4
Security Standards Stack
SOAP
WS-Security
WS-TrustSAMLWS-Federation
WS-Authorization
WS-SecureConversation
WS-SecurityPolicyXACML
XKMS
8/7/2019 WS SOA Security
5/66
Gustavo Alonso, D-INFK. ETH Zurich 5
Main Security Specifications
XML Signature (XMLDSIG)
Message Integrity and Sender/Receiver Identification
XML Encryption (XMLENC)
Message Confidentiality
WS-Security (WSS)
Securing SOAP Messages
SAML
Interoperable security metadata exchange
XACML
Access Control
8/7/2019 WS SOA Security
6/66
Gustavo Alonso, D-INFK. ETH Zurich 6
Other Security Specifications
WS-Trust and WS-Federation
Federating multiple security domains
WS-SecureConversation
Securing multiple message exchanges
WS-SecurityPolicy
Describing what security features are supported or needed
by a Web service
XrML
Digital Rights Management
XKMS
Key Management and Distribution
8/7/2019 WS SOA Security
7/66
XML Signature
8/7/2019 WS SOA Security
8/66
Gustavo Alonso, D-INFK. ETH Zurich 8
XML Signature Overview
Goals: Ensure integrity of XML messages; identify their
source/destination; ensure non-repudiation.
XML signature prescribes how to compute, store and verifythe digital signature of:
entire XML documents
parts of XML documents
anything that can be referenced from an URL, thisincludes non-XML objects, such as Images.
Complex and flexible standard:
It is possible to apply multiple signatures over the sameXML content
Supports a variety of codes and authentication protocols
Joint W3C/IETF standard, August 2001
8/7/2019 WS SOA Security
9/66
Gustavo Alonso, D-INFK. ETH Zurich 9
XML Signature Structure
(CanonicalizationMethod)(SignatureMethod)(
(Transforms)?(DigestMethod)(DigestValue)
)+(SignatureValue)(KeyInfo)?(Object)*
Reference to whathas been signed
Hash of the reference
The actual signature
Key used to verifythe signature
8/7/2019 WS SOA Security
10/66
Gustavo Alonso, D-INFK. ETH Zurich 10
XML Signature Simplified Example
Base-64 encoded
8/7/2019 WS SOA Security
11/66
Gustavo Alonso, D-INFK. ETH Zurich 11
Generating the signature
Reference Generation1.
Dereference the to access the XML content thatneeds to be signed
2.
Apply the Transforms3.
Compute the applying the to thetransformed content
4.
Store the result in the element
Signature Generation
1. Create the element2.
Transform it to canonical form3.
Compute the applying a
4.
Bundle it all together with the and elements
Note : what is actually signed is the , which contains a digest(hash) of the original content, which is only indirectly signed.
8/7/2019 WS SOA Security
12/66
Gustavo Alonso, D-INFK. ETH Zurich 12
Validating the signature
Reference Validation1.
Dereference the to access the XMLcontent that needs to be validated against the digest
2.
Apply the same Transforms3.
Compute a hash using the same
4.
Compare the with the result .
Signature Validation1.
Canonicalize the element
2.
Get the Key following the element3.
Compute the hash with the
4.
Compare it with the
8/7/2019 WS SOA Security
13/66
8/7/2019 WS SOA Security
14/66
Gustavo Alonso, D-INFK. ETH Zurich 14
Element
The reference element points to the resource that is beingdigitally signed (URI attribute)
There must be at least one Reference element (but more arepossible in the same signature)
Examples:
An element of the same documentURI=#CustomerInformation
The root of the container documentURI=
An external XML documentURI=http://www.swisscom.ch/order.xml
A fragment of an external documentURI=http://www.swisscom.ch/order.xml#Total
An external non-XML resourceURI=http://www.swisscom.ch/order.pdf
8/7/2019 WS SOA Security
15/66
Gustavo Alonso, D-INFK. ETH Zurich 15
Element
A Reference element contains a set of transform elements,which are applied in a pipelined fashion to the content of thereferenced resource
The same transformations (in the same order) should be usedwhen generating and validating a digest
Standard Transforms:
Canonicalization
Enveloped Signature Transform
Decrypt Transform
Optional Transforms:
Base-64
XPath Filtering
XSLT Transform
8/7/2019 WS SOA Security
16/66
Gustavo Alonso, D-INFK. ETH Zurich 16
Canonicalization (C14N)
The problem:
Signatures are sensitive to single bit changes
XML data can have multiple (and equivalent)serializations. Examples:
An XML document from a Windows system will useCR+LF, but can still be parsed in UNIX
Whitespace can be represented with TAB
Mismatch between data used by crypto algorithms (rawbytestream: octets) andthe XML representation (XML Infoset)
The solution:
Give a precise (and standard) procedure for producingXML strings out of XML infosets.
This procedure is called Canonicalization
8/7/2019 WS SOA Security
17/66
Gustavo Alonso, D-INFK. ETH Zurich 17
Canonicalization Example< PurchaseOrder >
2005 11 22 < /Date>
2005 11 22
Canonical Form
Original XML Document
8/7/2019 WS SOA Security
18/66
Gustavo Alonso, D-INFK. ETH Zurich 18
Some XML Canonicalization Rules1.
UTF-8 encoding
2. Linebreaks are normalized to LF (ASCII #xA)3.
Character and entity references are replaced4.
CDATA sections are replaced with their content
5.
XML declaration and DTD definition are removed6.
elements converted to
7.
Attribute value delimiters are set to double quotes8.
Superfluous namespace declarations are removed
9.
Default attributes are explicity added to elements10.
Namespace declarations are sorted before the attributes(also sorted)
For the whole set of rules, ref:
http://www.w3.org/TR/xml-c14n
8/7/2019 WS SOA Security
19/66
Gustavo Alonso, D-INFK. ETH Zurich 19
Enveloped Signature Transform
This signature is needed in order to sign an element which isthe parent of the (Otherwise, the signatureshould be used as input to compute itself, which makes itimpossible to compute)
This transform simply removes the element fromthe document
Enveloped-SignatureTransform
8/7/2019 WS SOA Security
20/66
Gustavo Alonso, D-INFK. ETH Zurich 20
Describing and storing the signature
These elements describe how a signature was computed andstore its value in encoded format:
The contains the Base-64 encoded value of the digest
The contains the Base-64 encoded valueresulting from encrypting the digest of the element with the key described in the
The describes the algorithm used tocompute the (e.g., SHA1)
The describes how the was computed (e.g., RSA-SHA1) using the
key
8/7/2019 WS SOA Security
21/66
Gustavo Alonso, D-INFK. ETH Zurich 21
element
The provides information about the key used tovalidate the
It is quite flexible:
The element can be omitted (The parties exchanging themessage agree on the key using an out-of-bandmechanism)
Key is embedded in the message
Key is referenced from the message
It supports several kinds of Keys used with differentcryptographic standards: DSA/RSA
X.509 certificates
PGP
The same element is used in XML Encryption
8/7/2019 WS SOA Security
22/66
Gustavo Alonso, D-INFK. ETH Zurich 22
XML Signature and SecurityXML Signature targets these security aspects:1.
Integrity of the message content/external resource:
Reference validation
2.
Integrity of the signature
Signature validation
3.
Identity of the source of the document
Signature validation
Warning: only if using a based onpublic/private key
What you see is what you sign:
Transforms modify and filter the data before it is signed,so they should be used carefully
8/7/2019 WS SOA Security
23/66
XML Encryption
8/7/2019 WS SOA Security
24/66
Gustavo Alonso, D-INFK. ETH Zurich 24
XML Encryption Overview
Goal: ensure confidentiality of XML Messages
Solution: obfuscate parts of an XML document, whilemaintaining a correct XML syntax
Features:
End to End (Multi-hop scenario)
Full or Partial encryption
Flexibility: different parts of a message can be read bydifferent parties using different keys
Challenges and problems:
Is an encrypted XML document still XML?
How to validate an encrypted XML document with respect
to its XML schema?
W3C Recommendation, December 2002
8/7/2019 WS SOA Security
25/66
Gustavo Alonso, D-INFK. ETH Zurich 25
XML Encryptionvs. XML Signature
XML Encryption complementary to XML Signature
Different purposes:
XML Encryption = Confidentiality
XML Signature = Integrity and Identity
Some overlap in the specifications (e.g., )
Difference:
XML Encryption. Encrypted XML is replaced by the element
XML Signature: Signed XML is referenced from the element
Warning: Encrypted data which is not signed can still be
tampered with!
8/7/2019 WS SOA Security
26/66
Gustavo Alonso, D-INFK. ETH Zurich 26
XML Encryption Scenario
Guarantee confidentiality at the SOAP message level(Selected parties may access different message parts)
Client
SOAPEncrypted XML
HTTPSSecurePoint to Point
Transport
Encrypted XML
Broker Service
SOAPEncrypted XMLEncrypted XML
HTTPSSecurePoint to Point
Transport
8/7/2019 WS SOA Security
27/66
Gustavo Alonso, D-INFK. ETH Zurich 27
XML Encryption Example
222-654-456Markus Bach100000
Markus Bach
Encrypted XML Document
Original XML Document
8/7/2019 WS SOA Security
28/66
Gustavo Alonso, D-INFK. ETH Zurich 28
XML Encryption Structure
??
Encrypted Value
Key Information(extends KeyInfo of
Digital Signature)
Additional Metadata
Reference toEncrypted Value
8/7/2019 WS SOA Security
29/66
Gustavo Alonso, D-INFK. ETH Zurich 29
Element
The container tag replaces the document elements thatare sent in encrypted form
Together with the encrypted elements , it contains metadataand attributes describing how to decrypt them ,
Attributes:
Type = (element | content ).Determine whether the plaintext is an entire XML element or only thecontent has been encrypted.
MimeType. Optional attribute describing the type of the encryptednon-XML element
Encoding. How the non-XML has been encoded
The specifies which algorithm has been used toencrypt the data. Currently supported are:
Triple-DES
AES (Advanced Encryption Standard) with 128, 256 (required) or 192(optional) bit key
8/7/2019 WS SOA Security
30/66
Gustavo Alonso, D-INFK. ETH Zurich 30
Base 64 Encoded
Element
This element stores or refers to the encrypted data:
container for binary encrypted data
BA234C96D1
reference to an URL of the encrypted data.Can include a pipeline of Transform elements like XML
Signature, that specify how to filter the referenced databefore it is decrypted
8/7/2019 WS SOA Security
31/66
Gustavo Alonso, D-INFK. ETH Zurich 31
Element
Describe the key used to encrypt the data.
Whereas in XML Signature, this is usually a public key, in XML Encryption
this is usually a shared encryption key.
In general, public keys can be safely included with a message. Instead, it isnot safe to embed shared keys!!
XML Encryption provides several mechanisms to agree/retrieve thedecryption key:
Key is omitted (out-of-band)
Key is referenced: These elements are used to identify which of the secret keys (sharedbetween the parties) should be used and how the shared key should beretrieved.With them, the same key can be used to encrypt different parts of thesame document
Key is regenerated:
Key is included in encrypted form:
8/7/2019 WS SOA Security
32/66
Gustavo Alonso, D-INFK. ETH Zurich 32
Sharing keys within the same message
It is possible to reuse the same element todecrypt multiple elements.
MyKey
MyKey
8/7/2019 WS SOA Security
33/66
Gustavo Alonso, D-INFK. ETH Zurich 33
Using XML Encryption
Encryption Process1.
Choose an algorithm (3DES, AES)
2. Choose a key and define how to represent it
Key is generated or looked up
Key is omitted from the message
Key is described in the section
3.
Serialize the XML data to a byte stream
Element (with tags)
Content (tags omitted)4.
Encrypt the byte stream
5.
Encode the result in the element6.
Build the element with the information
required to decrypt it
8/7/2019 WS SOA Security
34/66
Gustavo Alonso, D-INFK. ETH Zurich 34
Using XML Decryption
Decryption Process1.
Determine algorithm (3DES, AES)
2. Determine key
Key and algorithm could be agreed upon in advance
If Key is encrypted, decrypt it (this is recursive)
3.
Decrypt data
CipherValue (decode the embedded Base-64 byte stream)
CipherReference (dereference the URI and apply the specifiedTransforms before the data is decrypted)
4.
Process XML content: parse the serialized XML and substitute theoriginal element with the decrypted XMLelement (or content)
5.
Process non-XML content described by the MimeType andEncoding attributes of the element.
8/7/2019 WS SOA Security
35/66
Using XML Encryptiontogether with XML Signature
8/7/2019 WS SOA Security
36/66
Gustavo Alonso, D-INFK. ETH Zurich 36
XML Signature and XML Encryption
Message Confidentiality and Integrity are both importantrequirements of a secure message exchange.
XML Signature and XML Encryption have been designed towork together to achieve this.
Problem: in which order should they be applied? Sign orencrypt first?
Encryption metadata is sent in clear.If not signed, encrypted data/metadata could becorrupted by an attacker to prevent decryption of themessage.
If signatures are sent in the clear, attackers could stripthem from a message or replace them entirely withoutthe recipient noticing.
8/7/2019 WS SOA Security
37/66
Gustavo Alonso, D-INFK. ETH Zurich 37
Example 1: Encrypt the signed data
99
8/7/2019 WS SOA Security
38/66
Gustavo Alonso, D-INFK. ETH Zurich 38
Example 1: Encrypt the signed data
The signature is hidden inside the encrypted XML
The order is clear: 1. decrypt; 2. verify signature
Problem: the Encryption metadata is not protected with asignature
8/7/2019 WS SOA Security
39/66
Gustavo Alonso, D-INFK. ETH Zurich 39
Example 2: Sign the encrypted data
8/7/2019 WS SOA Security
40/66
Gustavo Alonso, D-INFK. ETH Zurich 40
Decrypt Transform in XML Signature
When a message is received, it may not be clear in which order signaturevalidation and decryption should be applied.
To make the order of encryption and signature explicit, the Decrypttransform has been added to the XML signature standard
This transform is used to distinguish whether the signature applies tothe or to the decrypted data.
The XML Signature processor will decrypt all referenced elements except the one identified by the element.
With this solution, default processing always applies decryption beforesignature verification; unless such transform is specified by the sender.
8/7/2019 WS SOA Security
41/66
WS-Security
8/7/2019 WS SOA Security
42/66
Gustavo Alonso, D-INFK. ETH Zurich 42
WS-Security Overview
The WS-Security standard applies XML security (XMLEncryption and XML Signature) to implement secure SOAP
message exchange across multiple and independent trustdomains
Goals: security at the message level (end-to-end)
Solution: apply encryption and signatures within a SOAPmessage independent of the transport.Parts of the message body can be encrypted, signatures arestored in the header.
WS-Security features support for:
Multiple signature technologies
Multiple encryption technologies
Multiple security token formats
OASIS standard, April 2004
8/7/2019 WS SOA Security
43/66
Gustavo Alonso, D-INFK. ETH Zurich 43
Message Security vs. Transport SecurityMessage Security
Disadvantages
Immature standards only partiallysupported by existing tools
Securing XML is complicated
Advantages
Different parts of a message canbe secured in different ways.
Asymmetric: different securitymechanisms can be applied torequest and response
Self-protecting messages(Transport independent)
Transport SecurityAdvantages
Widely available, maturetechnologies (SSL, TLS, HTTPS)
Understood by most systemadministrators
Disadvantages
Point 2 Point: The completemessage is in clear after each hop
Symmetric: Request and responsemessages must use same securityproperties
Transport specific
8/7/2019 WS SOA Security
44/66
Gustavo Alonso, D-INFK. ETH Zurich 44
Protecting SOAP Messages
Security Threats to a SOAP message:
A message could be read by an attacker
A message could be modified by an attacker
A message could be sent by an attacker
To address these threats, WS-Security applies a combinationof:1.
Encryption
(Ensure the confidentiality of the message)2.
Signatures(Verify the origin and the integrity of a message)
3.
Security Tokens(Authorize the processing of the message based on thecredentials associated with the message)
Messages with invalid signatures and incorrect or missingtokens are rejected.
8/7/2019 WS SOA Security
45/66
Gustavo Alonso, D-INFK. ETH Zurich 45
A Secure SOAP Message
Envelope
Body
Encrypted Body
Signatures for Bodyand for Tokens
Headerwsse:Security
Security Tokens
8/7/2019 WS SOA Security
46/66
Gustavo Alonso, D-INFK. ETH Zurich 46
Security Tokens
WS-Security supports a variety of authentication and authorizationmechanisms by including the corresponding tokens into the Securityheader of the message:
Simple tokens
Username/Clear Password
Username/Password Digest
Binary Tokens
X.509 certificates
Kerberos
XML Tokens
SAML assertions
XrML (eXtensible Rights Markup Language)
XCBF (XML Common Biometric Format)
Token reference
WS-SecureConversation
8/7/2019 WS SOA Security
47/66
Gustavo Alonso, D-INFK. ETH Zurich 47
Security Tokens and Identity
A security token can be used to claim the identity of the source of a message
Username/PasswordText is the simplest token used to conveyidentify but it is also not secure (SOAP messages should not contain passwords in clear)
Username/PasswordDigest deals with this problem:
Scott TigerXYZAAA91235212005-11-24T15:00:00Z
To produce the digest, the password is hashed together with atimestamp and a nonce.
Protection against reply attacks
The server must store the plain-text password
8/7/2019 WS SOA Security
48/66
Gustavo Alonso, D-INFK. ETH Zurich 48
Security Tokens and Authentication
A security token can be signed to authenticate a claim made bythe sender of the message
Signatures associated with tokens can be verified by the recipientto authenticate the identity of the sender.
Example: X509 certificates (public keys) should be signed in orderto provide authentication of the sender (proof of possession of thecorresponding private key)
RequesterWeb
Service
X509Token
SignaturePrivate Key Public Key
8/7/2019 WS SOA Security
49/66
Gustavo Alonso, D-INFK. ETH Zurich 49
Federated Security Domains
Different systems may belong to different security domainsthat use different security mechanisms and policies.
Although SOAP enables interoperability between thesesystems, the translation of security metadata betweendifferent domains remains a problem.
WS-Security is a first step towards providing standardizedsyntax and semantics for representing security information.
WS-Trust adds a standard interface for a security token service
provider used to:
Issue and Renew Security Tokens to be attached to a SOAPmessage with WS-Security
Validate Security Tokens from a different domain
Translate Security Tokens across domains that share a trustrelationship (WS-Federation)
8/7/2019 WS SOA Security
50/66
8/7/2019 WS SOA Security
51/66
Gustavo Alonso, D-INFK. ETH Zurich 51
WS-SecureConversation
The security handshake involving the creation of tokens and theirvalidation may impose a high performance overhead.
WS-SecureConversation defines a shared security context to bereused across the exchange of multiple messages.
The same combination of security credentials (authentication,authorization) and encryption keys can be reused
Once the conversation is established, the requester and the serviceshare a secret:
The client does not have to include the security metadata foreach message
The service does not have to revalidate the same tokens foreach message
This is implemented using a special token:
8/7/2019 WS SOA Security
52/66
SAMLSecurity Assertion Markup Language
8/7/2019 WS SOA Security
53/66
Gustavo Alonso, D-INFK. ETH Zurich 53
SAML Overview
The Security Assertion Markup Language (SAML) predates WS-Security,as it was standardized at OASIS in November 2002 (v1.0), August 2003(v1.1), March 2005 (v2.0)
Goal: enable loosely coupled identity management.
Solution: define a format and protocol for interoperable exchange of security information (or assertions) about subjects (human users orcomputer systems) that have to be identified within a certain securitydomain.
Use cases supported by standard profiles:
Single Sign On (SSO) and Single Logout
Identity Federation
Privacy-preserving identification
Securing Web service messages: SAML assertions are used as WS-Security tokens.
SAML also defines protocol for clients to request assertions from SAMLauthorities and for services to verify assertions with trusted SAML
authorities.
8/7/2019 WS SOA Security
54/66
Gustavo Alonso, D-INFK. ETH Zurich 54
Portable and Federated Identity
SAML enables Single Sign On and the transfer of identitycredentials across different trust domains.
Credentials established at the initial service, where the user isauthenticated, are forwarded to other services that can trustthem.
This is done without a centralized authentication registry thatshould be shared and trustedby everyone (example: Project Liberty).
ClientApplication
WebService(Airline)
Web Service(Travel Agency) WebService(Hotel)
8/7/2019 WS SOA Security
55/66
Gustavo Alonso, D-INFK. ETH Zurich 55
SAML Concepts
SAML uses XML to describesecurity assertions that can beunderstood across securitydomains.
SAML defines a standardprotocol to generate,exchange and processassertions.
SAML bindings map how aSAML document istransported:
SAML requires HTTPS
SAML can be used insideSOAP messages torepresentWS-Security tokens.
SAML Assertions and thecorresponding protocols areused for:
Authentication verificationof identity credentials.
Attributes informationassociated with subjects (e.g.,the user address or its thecurrent balance status of theaccount).
Authorization grant (or deny)access to a resource for anauthenticated subject. (As of SAML 2.0, this feature usesXACML).
Custom assertions
8/7/2019 WS SOA Security
56/66
Gustavo Alonso, D-INFK. ETH Zurich 56
SAML Assertion Metadata Examplesaml.ethz.ch
pautasso@inf.ethz.ch
statements
8/7/2019 WS SOA Security
57/66
Gustavo Alonso, D-INFK. ETH Zurich 57
Authentication Assertions
An Authentication Assertion Statement is produced by anauthentication authority (issuer) to claim that:
a subject (with some identification)
with a certain method (or context class)
at a certain time
was successfully identified.
Depending on the method, the authentication assertion canbe trusted with a certain level of confidence to represent thedigital identity of the subject for some period of time
AuthenticationAuthority
Credentials(User, Password)
Authentication
Assertion
8/7/2019 WS SOA Security
58/66
Gustavo Alonso, D-INFK. ETH Zurich 58
Authentication Methods
To describe how a subject identity was authenticated, SAML 2.0 definesthe following authentication context classes:
Internet Protocol Address
UserName/Password over HTTP or HTTPS
Secure Remote Password
IP Address and Username/Password
SSL/TLS Certificate Based Client Authorization
Kerberos Ticket
Public Key (X.509, PGP, SPKI, XML Signature)
Smartcard: One Factor, Two Factor
Telephone Number
Mobile: One Factor, Two Factor
Previous Session
Unspecified
8/7/2019 WS SOA Security
59/66
8/7/2019 WS SOA Security
60/66
Gustavo Alonso, D-INFK. ETH Zurich 60
SAML Protocols
SAMLAuthority
NameIdentifierMapping
Subject Web Service
SAMLAuthority
SingleLogout
AuthenticationRequest
AssertionQuery
SubjectManagement
8/7/2019 WS SOA Security
61/66
Gustavo Alonso, D-INFK. ETH Zurich 61
Putting it all together
Client Service
Provider
SAML
Authority
1. SOAP Request
2. Auth Needed
7. SOAP Response
TrustRelationship
3. Authentication Request (Login)
4. Authentication Assertion (AA)
5. Forward (AA)SAML Protocol
6. Verify (AA)
Optional
8/7/2019 WS SOA Security
62/66
XACMLeXtensibleAccess Control Markup Language
8/7/2019 WS SOA Security
63/66
Gustavo Alonso, D-INFK. ETH Zurich 63
XACML Overview
Goal: represent access control policies in XML
Solution: define an XML schema for representing authorization
rules to grant (or refuse) subjects the access to target resources toperform specific actions.
Features:
Fine grained control: targets referenced using URLs
Consistent with and building upon SAML
Benefits:
Interoperability of different security tools(Migration of rules through import/export)
Uniform way to specify access control policies
Reuse of generic access control service
Enable the consolidation of access control policies across theenterprise: centralization reduces costs
OASIS Standard released February 2003 (v1.0), August 2003 (v1.1)and March 2005 (v2.0)
8/7/2019 WS SOA Security
64/66
Gustavo Alonso, D-INFK. ETH Zurich 64
What is Access Control?
Authorization is the permission granted to a subject toperform some action on some target resource.
Authorization Rule
Rights management tools control whether a subject isgranted the authorization rights.
Access rights can be granted to individual subjects, but alsoto groups of subjects (or roles).
Subject Action TargetResource
8/7/2019 WS SOA Security
65/66
Gustavo Alonso, D-INFK. ETH Zurich 65
XACML Rule Example (Simplified)Allow Daniel to send a message
Daniel
uri: message
send
8/7/2019 WS SOA Security
66/66
XACML Architecture
Repository
PolicyAccess
Point (PAP)
XACMLPolicy
Policy Decision Point(PDP)
Policy EnforcementPoint (PEP)
AccessRequester
2
3 6
45
1
1 Policy Definition
2 Access Request
3 SAML Request
4 Policy Lookup
5 Policy
6 SAML Response
XACML works together with SAML to implement an authorizationauthority
TargetResource
Environment