SAP PI Principle Propagation

SAP NetWeaver Process Integration 7.1 1

SAP NetWeaverProcess Integration 7.1Principal Propagation in SAP NetWeaverProcess Integration 7.1

SAP Regional Implementation GroupSAP NetWeaver Product ManagementDecember 2007


1. Introduction2. Principal Propagation for SAP NW 7.03. Web Service Security and SAML4. Principal Propagation for SAP NW 7.1

Agenda



Agenda


Goal:Securely pass the identity of user ‘U’ across SAP PI to receiversystemRun the receiver application under the same identity as the senderapplication

Benefits:Dynamic configuration at the PI receiver channelPermissions of the receiver application are checked against theoriginal userUser can be audited in receiver system

Principal Propagation Concept

PIMSenderApplication

Sender System

UserU

ReceiverApplication

Receiver System

UserU

M

Authentication as of today, exemplarily shown with XI 3.0 protocol

– Communication paths are statically configured in the following sense:- Sender to IS: For Java proxies, an XI internally configured connection is always used. For ABAP proxies, the communication path is configured globally

as an SM59 HTTP destination where the credentials (user/password or certificate) are usually stored within the destination. Nevertheless, it is possibleto configure the destination as using the actual application user for logging into the IS.

- IS to receiver: In the XI directory, a set of receiver channels with static connection attributes and user credentials similar to SM59 destinations areconfigured. However, in each channel user credentials must be defined for logging into the receiver system. On message execution, a certain channel isdynamically selected from this set depending on the actual message properties and the configuration rules.

– This configuration model bears the following weaknesses with respect to user credentials:- Sender to IS:

Individual applications or individual messages can not use separately configured users for logging into the IS, but depend on the globally configuredconnection (Java proxies) or destination (ABAP proxies) in the sender system.When application users are propagated to the IS (ABAP proxies only), each application user must be maintained with the corresponding executionrights in the IS.

- IS to receiver:

Application users from the sender application can never be propagated by the IS to the receiver application as the users for logging into the receiversystem are statically configured in the IS’ receiver channels.

Principal propagation means the ability to forward the user context of a message unchanged from the sender to thereceiver. It enables authentication of a message in the receiver system with the same user that issued the message in thecorresponding sender system. Thus, the receiver application is virtually part of the sender application, and the permissionsand audit functions of the receiver application can be applied to the original user of the sender application

Principal propagation is supported by the following adapters:

– XI (for both ABAP and Java proxies)

– SOAP

– RFC

– WS-RM

Benefit of Principal Propagation

– enabling the XI 3.0 protocol and the new web service protocol (in the mediated scenario) for securely propagating the identity of thesubject running in the sender/WS consumer application to the receiver/WS provider system so that the inbound proxy/web service onthe receiver/WS provider system is executing under the same identity as the sender/WS consumer application.

– For NW 04/04s lean/quick solution based on SAP logon ticket/SAP assertion ticket.



Agenda


Principal Propagation in SAP NW 7.0 (1)

AdapterEngine

IntegrationServernon-SAP

Sender

Sender(NW04/s)

<P>, U

M

M

UserU

UserU

M

UserU

UserU

AdapterEngine

M

UserU

UserU

M M M

M MUserU

UserU

UserU

Receiver(NW04/s)

UserU

UserU

non-SAPReceiver

UserU

<XI 3.0>,[U]

<XI 3.0>,[U]

<P>,[U]

<XI 3.0>, logon ticket [U]<XI 3.0>, logon ticket [U]

Ticketing mechanism: based on SAP logon/SAP assertion ticketat transport levelmessage is executed under propagated user

at PI inbound side, different authentication mechanism possible

at PI outbound side, only SAP logon ticket supported

Approach for XI 3.0 / XI 7.0: Principal Propagation on transport level, using SAP logon ticket / SAPassertion ticket

Approach is mainly based on the SAP assertion ticket which is downwards compatible with the SAPlogon ticket being available since Release 4.6. SAP WebAs components (both J2EE and ABAPservers) directly use and consume the SAP assertion ticket for logging into the system for executingthe associated request. Therefore, a new ticket must be issued for a consecutive outbound call.

In general, the identity of a sender application user can only be propagated via a ticket or tokenmechanism. Basic authentication with user/password credentials are not possible because thepassword is not available for the identity to be propagated.

The only token mechanisms XI supports in XI 3.0 is the SAP assertion ticket (which is downwardscompatibly to SAP SSO ticket). Note that in NW 2007 also SAML assertion will be available

Principle approach:

– The user that is executing the message equals the user that is to be propagated.

– The credentials are propagated via the SAP Assertion Ticket (SAP Logon Ticket).

– SAP Logon Ticket: A SAP system generates a SAP-specific assertion containing the subject name of theactual user which is then impersonated in the target system. This assertion is signed by private key of thesender system. There must also be established a trust relationship between the sender and the targetsystem similarly to the X.509 certificate mechanism.

– On the inbound side, both SAP and non-SAP systems are supported

– On the outbound side, SAP backend systems are supported (understanding SAP logon tickets)

– Non-SAP systems might support SAP logon ticket authentication by using the SSOext.dll library


Principal Propagation in SAP NW 7.0 (2)

Supported protocols:SOAPRFCABAP/Java proxies

User to be propagated must exist at IE system as a service userwith appropriate roles for message processing

Availability:XI 3.0 SP19, Web AS ABAP 6.40 Kernel Patch 149PI 7.0 SP10, Web AS ABAP 7.00 Kernel Patch 79PI 7.1 SP0

Mapping of user names not supported yet

Principal propagation for BPM not supported yet

User to be propagated must exist at the IE system as a service user with the appropriate roles toexecute the message processing.

SOAP/Web Services

– Inbound: Any authentication mechanism possible

– Outbound: only SAP assertion ticket possible

RFC

– When a sender system sends a message to the RFC adapter, it must use a type-T destination with theoption “use SAP Logon ticket” switched on. Then RFC adapter of the Adapter Engine running on the J2EEWebAS must be configured to accept SAP Logon tickets and the user of the sender application would beimpersonated.

– On the receiver side, the adapter must either use destination services with the option “use SAP Logonticket” switched on. Furthermore, the RFC receiver adapter could support the sending of a SAP assertionticket directly.


Implementation at the Integratio Engine (IE)

Sender IEPipeline

Hugo

IS

Database

Pipeline

InboundPersist

IE EntrySave UC

Split (> 1 Child)Save UC for Childs

Release UC for Parent

BatchRecreate UC

SplitPersist

XI AdapterSend Logon Ticket

IE EntrySave UC


Database

Persist

Receiver IEPipeline

IE EntrySave UC


Database

Batch and RestartRecreate UC

End of ProcessingRelease UC

RestartRecreate UC

OutboundPersist

Persist

Batch and RestartRecreate UC



Msg Msg Msg

UC = User Context


Configuration at A Glance

Enable Principal Propagation on Integration Engines

Configure a Trust Relationship for SAP Assertion TicketsClient Side– Generate private/public key pair, and export the certificate

Server Side– Import client’s server certificate into secure storage– Add client to the Access Control List

Configure Sender to create assertion ticket

Configure Sender/Receiver Agreement in Integration Directory

Maintain users to be propagated on all involved components

For details, please refer to next slides

Maintain Users

– Users to be propagated must be maintained in the messaging components with the same name as in thesender system. For security reasons, we recommend that you create these users as users of type systemand not as dialog users. These users must be assigned the role SAP_XI_APPL_SERV_USER.


Configuration: Enable Principal Propagation onIECall TX SXMB_ADM to activate Principal Propagation

A service user XIPPUSER, and an RFC destinationSAPXIPP<Client No> are automatically createdKeeps user context in case of message restarts or during batchprocessing

Enable Principal Propagation on IE

– Call TX SXMB_ADM (Integration Engine - Administration), and run Configure Principal Propagation toactivate principal propagation on the Integration Server. This will create a service user XIPPUSER withrole SAP_XI_APPL_SERV_USER assigned to the same, and an RFC destination SAPXIPP<Client No> .

– Activation has the effect that the user context in message processing remains the same for allasynchronous locks and restarts. The context of the user to be propagated is impersonated again after amessage restart or during batch processing only if principal propagation is enabled for the involvedmessaging component (The ABAP messaging components are the Integration Server and the IntegrationEngines of the sender and receiver systems executing ABAP proxies).


Configuration: Trust Relationship for ABAPSystems

Call TX STRUSTSSO2On Client:

maintain system PSE,and export certificate

On Client:maintain system PSE,and export certificate

On Server:add client

system to ACL

On Server:add client

system to ACL

On Server:add client’s certificateto PSE’s certificate list

On Server:add client’s certificateto PSE’s certificate list

Configure a Trust Relationship

– Principal propagation is implemented using authentication via SAP assertion tickets between the involvedmessaging components. Each communication step along the way from the sender to the receiver requiresa separate authentication for each messaging component before the message is executed. This impliesthat the message is executed under the same user in all participating messaging components. Since anSAP assertion ticket is consumed during authentication, a new ticket is generated each time a message isforwarded to the next messaging component. Wherever you want to use an SAP assertion ticket forauthentication between a sending and a receiving messaging component, you have to configure a trustrelationship between the underlying application servers first.

– ABAP Client: maintain system PSE in TX STRUST

– ABAP Server: TX STRUSTSSO2- import certificate into system PSE’s certificate list

- add certificate to ACL


Configuration: Trust Relationship for JavaSystems (1)

Launch Visual Administrator Key Storage service

On Server:add client’s public-keycertificate into J2EE

Engine’s ticket keystore

On Server:add client’s public-keycertificate into J2EE

Engine’s ticket keystore

On Client:create private/publickey pair, and export

certificate

On Client:create private/publickey pair, and export

certificate


– Principal propagation is implemented using authentication via SAP assertion tickets between the involvedmessaging components. Each communication step along the way from the sender to the receiver requiresa separate authentication for each messaging component before the message is executed. This impliesthat the message is executed under the same user in all participating messaging components. Since anSAP assertion ticket is consumed during authentication, a new ticket is generated each time a message isforwarded to the next messaging component. Wherever you want to use an SAP assertion ticket forauthentication between a sending and a receiving messaging component, you have to configure a trustrelationship between the underlying application servers first.

– Java Client: create private/public key pair in VA Key Storage service

– Java Server:- In VA Key Storage service, import certificate

- In the Security Provider service, maintain the ACL for module EvaluateAssertionTicketLoginModule


Configuration: Trust Relationship for JavaSystems (2)

Launch Visual Administrator Security Provider service

On Server:maintain ACL for module

EvaluateAssertionTicketLoginModule

On Server:maintain ACL for module

EvaluateAssertionTicketLoginModule


Configuration: Sender System

Define for which message a ticket should be createdABAP Proxies: configure interface filter in TX SXMB_ADM

Java Proxies: define interface filter in PP_Validate.ini fileRFC: for RFC destinations, select respective checkbox in TX SM59

SOAP: client specific

Configure Sender

– For the various protocols and adapters that support principal propagation, you have to configure for whichmessages an SAP assertion ticket is to be created for the application user.

– ABAP Proxies- Call transaction SXMB_ADMIN, and choose Configure Principal Propagation.

- Choose Define Interfaces, and maintain interface name, interface namespace, and user in appropriate table

- Entries with an asterisk (*) are allowed in all fields. If you enter an asterisk only, all interfaces, namespaces, orusers are considered.

– Java Proxies- maintain file PP_Validate.ini. It contains the interfaces and users for which you want to activate principal

propagation. You can find this file in the directory \usr\sap\<SID>\SYS\global\xi. If it does not exist, principalpropagation is switched off by default.

- Create or modify the file PP_Validate.ini as follows (one entry per line): interface namespace, interface name,user

- Entries with an asterisk (*) are allowed in all fields. If you enter an asterisk only, all interfaces, namespaces, orusers are considered.

- (Set the property com.sap.aii.proxy.xiruntime.principalPropagation=true in file\usr\sap\<SID>\SYS\global\xi\jpf.properties)

– RFC Sender- RFC sender programs use two different methods to obtain the necessary information for issuing RFC calls: An

RFC program uses either an RFC destination (ABAP sender system) or a property file according to the RFClibrary for external RFC client programs.

- For each method, you should specify that an SAP logon ticket or an SAP assertion ticket has to be created for thecall. In an RFC destination of type G or T, for example, there is an explicit checkbox specifying that an SAPassertion (logon) ticket should be created.

– SOAP Sender- The SOAP client itself must be able to issue SAP assertion tickets. If the sender is an SAP program, an HTTP

destination of type G can be used. If the sender is a SOAP (receiver) adapter, simple principal propagation canbe used.


Configuration: Agreement

Launch the Integration Directory, and maintain agreementsSender agreement Save user context on PI inboundReceiver agreement Send user credentials over ticket

Select checkboxPropagate PrincipalSelect checkbox

Propagate Principal

Configure Principal Propagation in the Integration Directory

– In the Integration Directory, sender and receiver agreements can be configured to propagate useridentities, simply set the Principal Propagation flag.

– Sender Agreement: Save the user context on Inbound

– Receiver Agreement: Send the user credentials over the SAP Logon Ticket



Agenda


Web Service Infrastructure in SAP NW PI 7.1

Support for point-to-point and mediated (=over PI) scenariosboth scenarios configurable in Integration Directory

Authentication methods supported by WS infrastructureTransport Level (security as part of the HTTP transport)– http over SSL– Basic authentication (user name / password)– X.509 client certificate– SAP Assertion Ticket

Message Level (security as part of the SOAP message)– Username Token– X.509 certificate token– XML Signature– XML Encryption– SAML assertion (SAML 1.1)

Authentication can be performed either on the transport level (e.g. credentials are sent via HTTPcommunication mechanisms) or on the message level where credentials are sent within the SOAP messageitself. In the latter case, the WS-Security header is used which defines a SOAP header containing thecorresponding credential data.

Authentication Mechanisms– Username/Passwort (basic mode):

- Username and password of a subject are directly sent for authentication and directly used for logging into the target system.

- Credentials are transported in HTTP 1.0 header field.

- User is authenticated directly with the user name.

– X.509 certificate authentication:

- A signature created with a private key together with a X.509 certificate (containing the associated public key) is sent to the targetsystem and thus proves the identity of the subject. As a side-effect, the integrity of the signed message contents is guaranteed. Inthe target system, the certificate must be checked as a trusted one (in general by having a chain of trusted CA certificatesavailable) and a mapping from the certificate to an actual subject must have been configured or implemented.

- Credentials are transported either on transport level (SSL Handshake before HTTP communication proves validity of clientcertificate ) or on message level (Valid message signature and certificate in WS-Security header = XML Signature).

- User is authenticated by a mapping from user name in certificate to actual user.

– SAP Logon Ticket:

- A SAP system generates a SAP-specific assertion containing the subject name of the actual user which is then impersonated inthe target system. This assertion is signed by private key of the sender system. There must also be established a trust relationshipbetween the sender and the target system similarly to the X.509 certificate mechanism. This mechanism is only available betweenSAP systems.

- Credentials are transported either as HTTP cookie or as a short-lived assertion ticket transported via HTTP header field.

- User is authenticated with the user name contained in the SAP logon ticket.

– SAML assertions

- A SAML assertion containing the subject name is created and signed by a trusted attester system against which the sendersystem is able to authenticate the subject. This assertion also contains a signature with respect to the entire message proving thelinkage of the assertion to the message contents. SAML assertions are used in two flavors where either the sender itself sends theSAML-enriched messages to the target system (holder-of-key) or the attester forwards the message to the target system (sendervouches). In the target system - similar to X.509 certificates- there has to be established a trust relationship to the attester and amapping of the subject name to the actual user has to be available.

- Credentials are transported as SAML assertion in WS-Security header.

- User is authenticated by a mapping from user name in certificate to actual user.


What is WS Security?

WS Security is an OASIS standard based on an IBM andMicrosoft proposal providing message level security forSOAP messages by using existing standards:

Confidentiality and integrity using XML Signature and XMLEncryption.Authentication using X.509, Username, SAML and KerberosSecurity tokens.

WS Security extends a SOAP message by oneor more wsse:Security headers which containssecurity information for each recipient.

WS Security provides end-to-end security forSOAP messages. Single sign on is providedby using security tokens like SAML.

Sec. Header

Body

WS Security is an OASIS standard based on an IBM and Microsoft proposal providing messagelevel security for SOAP messages by using existing standards:

– Confidentiality and integrity using XML Signature and XML Encryption.

– Authentication using X.509, Username, SAML and Kerberos Security tokens.

WS Security extends a SOAP message by one or more wsse:Security headers which containssecurity information for each recipient.

WS Security provides end-to-end security for SOAP and SOAP with attachment messages. WS-Trust, one component of the private WS-framework initiative, proposes protocols for the exchangeand validation of security tokens used as described within WS-Security. SAML assertions are onesuch supported security token format.

Benefits of WS Security Standards, and especially SAML

– Platform neutrality – SAML abstracts the security framework away from platform architectures andparticular vendor implementations. Making security more independent of application logic is an importanttenet of Service-Oriented Architecture.

– Loose coupling of directories – SAML does not require user information to be maintained andsynchronized between directories.

– Improved online experience for end users – SAML enables single sign-on by allowing users toauthenticate at an identity provider and then access service providers without additional authentication. Inaddition, identity federation (linking of multiple identities) with SAML allows for a better-customized userexperience at each service while promoting privacy.

– Reduced administrative costs for service providers – Using SAML to "reuse" a single act of authentication(such as logging in with a username and password) multiple times across multiple services can reduce thecost of maintaining account information. This burden is transferred to the identity provider.

– Risk transference – SAML can act to push responsibility for proper management of identities to the identityprovider, which is more often compatible with its business model than that of a service provider.


What is SAML?

SAML (Security Assertion Markup Language) is an XMLstandard defined by OASIS to exchange security information

Building BlocksAssertions: statements about a subject. This could be regardingeither an authentication, attribute information, or authorizationpermissionsProtocols: SAML defines request/response protocols for obtainingassertions, e.g. Assertion Query and Request ProtocolProtocol Bindings: defines how SAML protocols map to transportand messaging protocols, e.g. SAML SOAP BindingProfiles: define how assertions, protocols, and bindings arecombined for particular usage scenarios

Use Cases and ProfilesSingle Sign On in Web SAML browser artifactsSecuring Web Services SAML token profiles

SAML (Security Assertion Markup Language) is an XML standard that defines a language to exchange security information between partners.The SAML standard is driven by the OASIS (Organization for the Advancement of Structured Information Standards). SAML uses assertionsthat contain statements about a subject, authentication, authorization and attributes. As its name suggests, SAML allows business entities tomake assertions regarding the identity, attributes, and entitlements of a subject (an entity that is often a human user) to other entities, such asa partner company or another enterprise application.

How is SAML being used?

– Web SSO: In Web SSO, a user authenticates to one web site and then, without additional authentication, is able to access somepersonalized or customized resources at another site. A principal authenticates at the identity provider and is subsequently appropriatelyrecognized (and given corresponding access/service) at the service provider. SAML browser artifacts are used for authenticating Web-based access from a Web browser.

– Securing Web Services: SAML assertions can be used within SOAP messages in order to convey security and identity informationbetween actors in web service interactions. The SAML Token Profile produced by the OASIS Web Services Security TechnicalCommittee specifies how SAML assertions should be used for this purpose with the WS-Security framework.

SAML Components

– Assertions: SAML allows for one party to assert security information in the form of statements about a subject. For instance, a SAMLassertion could state that the subject is named “John Doe”, has an email address of [email protected], and is a member of the“engineering” group. An assertion contains some basic required and optional information that applies all assertions, and usually containsa subject of the assertion, conditions used to validate the assertion, and assertion statements. SAML defines three kinds of statementsthat can be carried within an assertion:

- Authentication statements: These are created by the party that successfully authenticated a user. At a minimum, they describe theparticular means used to authenticate the user and the specific time at which the authentication took place.

- Attribute statements: These contain specific identifying attributes about the subject (e.g., that user “John Doe” has “Gold” cardstatus).

- Authorization decision statements: These define something that the subject is entitled to do (e.g., whether “John Doe” is permittedto buy a specified item).

– Protocols: SAML defines a number of generalized request/response protocols e.g Authentication Request Protocol, Single LogoutProtocol, Assertion Query and Request Protocol etc (e.g. protocols that allow service providers to request or query for an assertion, askfor a subject to be authenticated, create and manage name identifier mappings etc).

– Bindings: SAML bindings detail exactly how the various SAML protocol messages can be carried over underlying transport protocols.Mappings from SAML request-response message exchanges into standard messaging or communication protocols are called SAMLprotocol bindings, for instance, the SAML SOAP Binding defines how SAML protocol messages can be communicated within SOAPmessages.

– Profiles: typical use cases for assertions, protocols, and bindings. SAML profiles define how the SAML assertions, protocols, andbindings are combined and constrained to provide greater interoperability in particular usage scenarios. For instance, the Web BrowserSSO Profile specifies how SAML authentication assertions are communicated between an identity provider and service provider toenable single sign-on for a browser user. Another example, SAML token profile of WS-Security that specifies how SAML assertions canbe used to provide message security.

mailto:[email protected]


Sender-Vouches Confirmation Method

Issuer provides SAML assertion to WS Consumer

WS Consumer adds SAML assertion to WS request

The requester signs both the SAML assertion and the message bodyusing its private key

Prerequisite: The intermediary is able to vouch for integrity of assertionand message body because a trust relationship between backendsystem and intermediary is established

Trust Relationship

Attester

Backend System /WS ProviderClient Intermediary /

WS Consumer

Assertion Issuer

Just providing assertions from an asserting party to a relying party may not be adequate for a secure system. How does therelying party trust what is being asserted to it? In addition, what prevents a “man-in-the-middle” attack that grabs assertionsto be illicitly “replayed” at a later date? SAML defines a number of security mechanisms that prevent or detect such attacks.The primary mechanism is for the relying party and asserting party to have a pre-existing trust relationship, typicallyinvolving a Public Key Infrastructure (PKI).To validate and process an assertion, the receiver needs to establish the relationship between the subject of each SAMLsubject statement and the entity providing the evidence to satisfy the confirmation method defined for the statements (i.e.the attesting entity). The two methods for establishing this correspondence are Holder-of-Key (HOV) and Sender-Vouches(SV).Sender-Vouches: Signed

– The request contains a sender-vouches SAML assertion. The Assertion and the Body elements are signed. A reference to the certificateused to verify the signature is provided in the header. The response does not contain a security header.

– In this scenario, the basis of trust is the Requester's certificate. The Requester's private key is used to sign both the SAML Assertionand the message Body. The Responder relies on the Requester, who vouches for the contents of the User message and the SAMLAssertion. Essentially, here the message sender "vouches" for the identity of a subject.

– In contrast to holder-of-key, for sender-vouches there is no separate attester, but the sender can generate the assertion itself acting as aSAML attester on its own behalf. The signature for the SAML assertion is not necessary in this case because integrity is alreadyguaranteed by the overall signature.

– You can use the sender-vouches confirmation method for SSO scenarios where the WS intermediary system has a trust relationshipwith the back-end system. This scenario defines four different entities: (1) a client, (2) an intermediary, (3) SAML issuer, and (4) a back-end system that is the WS provider.

– The following steps describe in more detail the lifetime of a request using the SAML sender-vouches profile:- The client sends a request to the intermediary. This request can be of any kind but must contain valid authentication information to log the client on to

the intermediary.- The intermediary authenticates the client. To process the request, the intermediary needs to retrieve information from the back-end system using Web

Services forwarding mechanisms for the client’s authentication information.- To forward the client’s authentication, the intermediary needs to add a SAML assertion to the request. This assertion is provided by the issuer. To get it

the intermediary needs to forward all necessary login information to the issuer, which in return creates the SAML assertion.- The assertion is added to the Web service request. To vouch for the integrity of the SAML assertion and the payload of the Web service request both

are signed by the intermediary using a digital signature. The intermediary is able to vouch for the SAML assertion because there is an explicit trustrelationship between the back-end system and the intermediary, which enables the back-end system to verify the digital signature.

- The Web service request containing the SAML assertion is now sent to the back-end system.- The back-end system attempts to verify the SAML assertion. Other than checking the correctness of the SAML assertion, the back-end system also

verifies that the issuer is trusted and there is an existing trust relationship between the intermediary and the back-end system. After successfulverification, the client is logged on to the system and the request is processed.

- The back-end system sends a response to the intermediary. The intermediary uses the received data to complete the client’s request and send aresponse to the client.

Glossary:– Attester: The attester vouches for the correctness of the SAML assertion. The attester has a predefined trust relationship with the

responder. A SAML assertion can only be regarded as valid, if the attester has signed it.– Issuer: The issuer actually issues the SAML assertion. The issuer is known to the responder and regarded as trustworthy. In this

scenario issuer and attester can be regarded as one entity.


Holder-of-Key Confirmation Method

The assertion issuer signs the SAML assertion

The requester signs the message body

Basis of trust is the assertion issuer’s certificate. The responder relieson the assertion issuer to have issued the assertion to an authorizeduser

Trust Relationship

Attester

ResponderRequester

Issuer

Holder-of-Key

– The request contains a holder-of-key SAML assertion. The assertion is signed by the assertion issuer withan enveloped signature. The certificate used to verify the issuer signature is contained within the assertionsignature. The message body is signed by the Requester. The certificate used to verify the Requester'ssignature is contained in the assertion SubjectConfirmation. The response does not contain a securityheader.

– In this scenario, the basis of trust is the Assertion Issuer's certificate. The Assertion Issuer's private key isused to sign the SAML Assertion for the User. The Responder relies on the Assertion Issuer to haveissued the assertion to an authorized User.

– The following steps describe in more detail the lifetime of a request using the SAML holder-of-key profile:

- The requester requests SAML SSO ticket

- The attester requests assertion from issuer

- The attester returns SAML assertion with enveloped signature

- The user stores ticket for period of validity

- The user includes SAML assertion, signs body and sends request to server

- The responder authenticates the user

- The server sends response to user



Agenda


Principal Propagation in SAP NW PI 7.1 (WSAdapter) (1)

AdapterEngine

IntegrationServernon-SAP

Sender

Sender(NW04/s)

<P>, U

M

M

UserU

UserU

M

UserU

UserU

AdapterEngine

M

UserU

UserU

M M M

M MUserU

UserU

UserU

Receiver(NW04/s)

UserU

UserU

non-SAPReceiver

UserU

<XI 3.0>,[U]

<XI 3.0>,[U]

<P>,[U]

<XI 3.0>, [U]<XI 3.0>, [U]

WSAdapter

WSAdapter

UserU

Sender(WS)

<WS>UserU

M[U]

SAML

<WS>

Receiver(WS)

UserU

UserU

M[U]

SAML

SAP NW 7.0 solution supported in SAP NW PI 7.1

SAML is just another ticket-based authentication mechanism

NW04(s) solution also works for WS adapter, based on SAML Assertions (security assertion markup language)

Principal Propagation on Message Level: This approach forwards the identity data within the message itself.

Advantage of a SAML assertion is that it is connected to the message by a digital signature whereas the SAPassertion ticket would be loosely attached to a message.

The purpose of a SAML assertion is to transport principal data of a principal identity in a secure way where theassertion is generated by a trusted attester system.

Overall Mechanism:– An application executing under user U calls a service where it is determined upon configuration whether U’s principal

data are to be propagated to the IS. If this is the case, a SAML assertion is generated. On message receipt, the IS firstchecks the SAML assertion. If the assertion is not correct, it immediately rejects the message and sends back an errorto the sender system. Note that it is necessary here that the IS has a trust relationship to the attester which has to beconfigured in the IS. If the assertion is correct, the principal data of the SAML assertion are extracted and the SAMLassertion itself is discarded. Now the IS must guarantee that the principal data are attached to the actual message andthat they are not compromised by any means.

– When sending an ESI message to the final receiver the IS first determines whether the U’s principal data are to bepropagated to the receiver. If this is the case, the IS creates a new SAML assertion containing the original principaldata. Thus, the IS always implements the SAML attester role. On message receipt, the web service consumer just actsin the ordinary way as in the P2P case by checking the SAML assertion and, if successful, impersonating the userassigned to U’s principal data. In general this will be just the user with the same name as U.

SAML assertions:

– A SAML assertion containing the subject name is created and signed by a trusted attester system against which thesender system is able to authenticate the subject. This assertion also contains a signature with respect to the entiremessage proving the linkage of the assertion to the message contents.

– SAML assertions are used in two flavors where either the sender itself sends the SAML-enriched messages to thetarget system (holder-of-key) or the attester forwards the message to the target system (sender vouches). In the targetsystem - similar to X.509 certificates- there has to be established a trust relationship to the attester and a mapping ofthe subject name to the actual user has to be available.

– Identity is described by a structured XML element (dedicated SAML tag AuthenticationStatement) with componentsprincipal name, SAML issuer/attester, and user store (e.g. this may be a SAP system name and SAP client)


Principal Propagation in SAP NW PI 7.1 (WSAdapter) (2)

Approach:

Identity is described by a structured XML element (SAML tagAuthenticationStatement) with following components

principal nameSAML issuer/attesteruser store (e.g. SAP system name, and SAP client)

Based on Sender-Vouches Confirmation Method

Supported Protocol: WS-RM

User to be propagated must exist at IE system as a service userwith appropriate roles for message processing

SAP NetWeaver enables you to use the Sender Vouches Subject Confirmation method to confirm asubject with SAML token profile authentication. For this subject confirmation method, the WSintermediary system acts also as a SAML assertion issuer. The WS intermediary authenticates theclient and forwards to the back-end WS provider the authentication information for the WSconsumer using a SAML token profile. The WS provider, in turn, authenticates access based on itstrust relationship with the intermediary system.


Configuration at A Glance

Enable Principal Propagation on Integration Engines

Configure a Trust Relationship between WS Consumer andWS Provider

Configure Trusted Issuers

Configure Sender/Receiver Agreement in Integration Directory

Maintain users to be propagated on all involved components

Enable Principal Propagation on IE

– See 7.0


– Two trust relationships required:- Do I trust the assertion, hence do I trust the consumer or Certificate Authority (CA) that issued the signature? So,

provider has to trust consumer (SSO trust).

- Do I trust the issuer of the assertion, and hence the user that is the subject of the assertion? Which user shouldbe logged in?

Configure Principal Propagation in the Integration Directory

– WS logical port for consuming a WS, and WS service endpoint for providing a WS are automaticallycreated with appropriate security settings

Maintain Users

– See 7.0


Configuration: Trust Relationship for JavaSystems

Launch NetWeaver Administrator Configuration ManagementTrusted Systems

Use wizard to add new trusted systemTicket key store and ACL are automatically maintained


– Java:- Visual Administrator has been replaced by NetWeaver Administrator (NWA)

- You can use the Web services security SAML configuration functions of the NWA to configure system trustbetween the systems involved in the SAML Token Profile SSO process.

– ABAP: see 7.0


Configuration: Trusted Issuer (Optionally)

In Consumer System (Sender), run report WSS_INFOprovides information about how issued SAML assertion will look like

SAML contains

– subject: user for which SAML assertion has been issued

– Digital signature

Subject = <SID>/<Client>::<User Name>, e.g. BXT/100:PROPAGATEME

Issuer = <SID>/<Client>, e.g. BXT/100

Attester = PSE


Configuration: Trusted Issuer

In Provider System (Receiver), run report RSUSREXTIDFor each propagated user, maintain user mapping

User: Propagated UserExternal ID type: SAPrefix: <SID>/<Client>::Issuer: Subject Key Identifier of certificate

For all propagated users, a user mapping has to be maintained

– Use multiple selection functionality for mass configuration

User mapping clarifies following questions:

– Do I trust the issuer of the assertion, and hence the user that is the subject of the assertion?

– Which user should be logged in?

Optionally, maintain user mapping either directly in table USREXTID, or via table view VUSREXTID


Configuration: Communication Channel andAgreement

Launch the Integration Directory, and maintain channelsSender Channel Verify SAML assertion, and save user contextReceiver Channel Create SAML assertion with user subject

For Adapter Type WS,select Authentication

Method SAML 1.1 SenderVouches Assertion

For Adapter Type WS,select Authentication

Method SAML 1.1 SenderVouches Assertion


Copyright 2007 SAP AG. All Rights Reserved

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without priornotice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, System i, System i5, System p, System p5, System x, System z,System z9, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, POWER5+, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AGin Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document servesinformational purposes only. National product specifications may vary.

The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any form or for any purpose without the express prior written permission ofSAP AG.

This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This document contains only intended strategies, developments, and functionalities ofthe SAP® product and is not intended to be binding upon SAP to any particular course of business, product strategy, and/or development. Please note that this document is subject to change and may bechanged by SAP at any time without notice.

SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of the information, text, graphics, links, or other items contained within thismaterial. This document is provided without a warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.

SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. This limitation shall notapply in cases of intent or gross negligence.

The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you may access through the use of hot links contained in these materials anddoes not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pages.

Documents

SAP PI Principle Propagation