web service security in sap netweaver ce service security in sap netweaver ce sap netweaver product...
TRANSCRIPT
Web Service Security in SAPNetWeaver CE
SAP NetWeaver Product Management Security
June 2008
© SAP 2008 Page 2
Agenda
1. Secure and Reliable Web Services – A short primer on StandardsInteroperability and StandardsQuality of Service in SOA: WS-Security & WS-Reliable Messaging
2. Web Services Development in SAP NetWeaver CEApproaches in Web Services DevelopmentJava EE 5 Web Service tools in SAP NetWeaver Developer StudioWeb Services in Java EE
3. Configuring Security and ReliabilityDesign-time configuration in SAP NetWeaverRuntime configuration in SAP NetWeaverAutomating Web Service Consumer Configuration
4. Design- and Runtime Interoperability in Heterogeneous LandscapesConsuming a secure SAP Web Service in Microsoft .NET
© SAP 2008 Page 3
Definition of Interoperability
The IEEE defines interoperability as:
The ability of two or more systems or components toexchange information and to use the informationthat has been exchanged*
* Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEEStandard Computer Glossaries. New York, NY: 1990
© SAP 2008 Page 4
Interoperability – The Value Of Standards
Interoperability is achieved by standards, supports the seamless exchange anduse of business information
ServiceInfrastructure
ServiceInfrastructure
ServiceInfrastructure
ServiceInfrastructure
BusinessApplicationBusiness
ApplicationBusiness
ApplicationBusiness
Application
Semantic InteroperabilityApplications understand and correctlyuse the information being exchanged
Semantic InteroperabilityApplications understand and correctlyuse the information being exchanged
Technical InteroperabilitySystems are connected and can
exchange information
Technical InteroperabilitySystems are connected and can
exchange information
© SAP 2008 Page 5
Platform BPlatform A
Role of Web Service Standards
Web Service (WS) standards define the format of the message in transit toguarantee the interoperable exchange between service consumer and provider ona technical levelWeb Service Standards don’t specify any infrastructure- or application-specificaspects, such as
APIs or programming languages that applications must use to send or deliver messages –these are always platform-specificRuntime architecture and components
Web ServiceConsumer
Web ServiceConsumer
SourceInfrastructure
SourceInfrastructure
DestinationInfrastructureDestination
Infrastructure
Send Deliver
Web ServiceProvider
Web ServiceProvider
Message
Scope of Web ServiceStandards
API API
© SAP 2008 Page 6
SOAP on its own does not provide anyQuality of Service (QoS) mechanisms forWeb Services, e.g.
Authentication, integrity & confidentialityNon repudiation of origin or receiptGuaranteed delivery of messages
But: SOAP has been designed to be simpleand extensible
Two additional specifications have been submitted to the standardsbody (OASIS) and were approved as an industry standard:
WS-Security for implementing security functions such as integrity andconfidentiality in SOAP messagesWS-Reliable Messaging to guarantee message delivery over SOAP andHTTP
Motivation for advanced Web ServicesStandards
SOAP EnvelopeSOAP Envelope
SOAP Header
SOAP Body
Data
SOAP message format
© SAP 2008 Page 7
Motivation for Security in Web Services
Assure confidentiality of sensitive data in-transit over unsecured networks,independent from the transport protocol (e.g. HTTP, JMS)
Assure data integrity to protect a service provider from processing malformedmessages
Authenticate service users to restrict access
Web ServiceConsumer
Web ServiceConsumer
Web ServiceProvider
Web ServiceProvider
a&8#73<XML><XML>
Web ServiceConsumer
Web ServiceConsumer
Web ServiceProvider
Web ServiceProviderqty=10
qty=1050
qty=50
Web ServiceConsumer
Web ServiceConsumerId=joe
Web ServiceProvider
Web ServiceProviderId=joe ?
© SAP 2008 Page 8
WS-Security Overview
WS-Security was submitted to the OASIS standards body in Sept.2002, was approved as an OASIS Standard in April 2004 (v1.0) andFebruary 2006 (v1.1)
WS-Security basically defines a new SOAP Header, the WS-SecurityHeader
This new SOAP Header contains all relevant security metadata tosecure a SOAP message, such as
Security Tokens to carry securityinformation (e.g. authentication oridentity data)A Timestamp to protectagainst Replay AttacksSignatures to protectagainst message tamperingEncrypted Keys and Datato protect confidentialinformation
Supported version inSAP NetWeaver CE 7.1: WS-Security 1.0
SOAP EnvelopeSOAP Envelope
SOAP Header
SOAP Body
Data
Security Token
Timestamp
Signature
Encrypted Key+ Data
WS-SecurityHeader
WS-Security Header BlockIn a SOAP message
WS-Security
© SAP 2008 Page 9
Cryptographic Concepts Used in WS-Security –Digital Signatures
Digital Signatures protect the integrity of the message and help toreveal secret or improper modification of the data
Processing steps:1. Computation of Hash2. Encryption of
Hash withWeb Service (WS)Consumerprivate key
3. Decryption ofHash withWS Consumerpublic key
4. Re-calculation of Hash5. Comparison of both Hash values
Message
Messagewith Signature& Public Key
Certificate
Service ConsumerPrivate key
A3d641HashA3d641
Service ConsumerPublic keyCertificate
1
2
3 4
A3d641
5
ServiceConsumer
ServiceConsumer
ServiceProviderServiceProvider
A3d641
Message
© SAP 2008 Page 10
Cryptographic Concepts Used in WS-Security –Encryption
Data is encrypted with a secret symmetric key. The secret key itself is encryptedwith the provider’s public key
Processing steps:1. Encryption of message with secret key2. Encryption of secret key with provider‘s public key3. Decryption of secret key with provider‘s private key4. Decryption of message with secret key
Service ProviderPrivate Key
Service ProviderPublic KeyCertificate
Message (encr.)with Session Key
(encr.)secretSession
Key
1
3
4
2
ServiceConsumer
ServiceConsumer
ServiceProviderServiceProvider
Message
secretSession
Key
Message
© SAP 2008 Page 11
WS-Security Header of a Signed SOAPMessage
SOAP EnvelopeSOAP Envelope
SOAP Header
SOAP Body
Data
WS-Security Header
Security Token (X.509 Cert)
Timestamp
Signature
SignatureValue
KeyInfo
SignedInfo
SignatureMethod (e.g. RSA)
Reference (#Timestamp)
Reference (#Body)
Syntax given by XML Signature1.0 W3C Recommendation<Signature> element in SOAPsecurity header<SignedInfo> contains pointerswith hash values (<Reference>
childs) to signed message parts<SignatureValue> containsSignature (encrypted digest)<KeyInfo> contains reference topublic key for signatureverification
© SAP 2008 Page 12
WS-Security Tokens and Timestamp
Security Tokens identifying principals and keysXML Token (e.g. Username token, defined by WS-Security Standard)<wsse:UsernameToken><wsse:Username>alice</wsse:Username><wsse:Password>2secret4u</wsse:Password>
</wsse:UsernameToken>
Binary Token encapsulating binary objects (e.g. X.509 Certificate Token, defined byWS-Security Standard)
Timestamp to detect replay attacks<wsu:Timestamp xmlns:wsu=… ><wsu:Created>2008-09-09T12:10:01Z</wsu:Created>
</wsu:Timestamp>
© SAP 2008 Page 13
Motivation for Reliable Messaging in WSQoS Requirements in a Sample Scenario
Using an inventory management client on mobile devices, stock takersprocess stock counting and transfer the data via SOAP messages to aWeb Service running on the central inventory management server
Stock takers are working at remote warehouses and are connected to theserver via a VPN over the Internet using mobile phone networks
Quality of Service requirements of the scenario:No submission of duplicate inventory counts to the central inventorymanagement serverIntermittent service interruption in the network connection must betolerated
Mobile InventoryClient
InventoryManagement Server
Network
(Mobile Phone Network,Internet)
Web ServiceConsumer
Web ServiceConsumer
Web ServiceProvider
Web ServiceProvider
© SAP 2008 Page 14
Confirmation(SOAP/HTTP Response)
Motivation for Reliable Messaging in WSFailure Situations in the Scenario (1/2)
Failure Situation: SOAP Request with the inventory counts is lost dueto a network failure
The Mobile Inventory Client and the Inventory Management Server arestill in a consistent state since neither of them has completed theservice invocation
Error-handling must be implemented on part of the Mobile InventoryClient, e.g. by re-submitting the failed request
Mobile InventoryClient
InventoryManagement ServerInventory Counts
(SOAP/HTTP Request)
Web ServiceProvider
Web ServiceProvider
Web ServiceConsumer
Web ServiceConsumer
© SAP 2008 Page 15
Motivation for Reliable Messaging in WSFailure Situations in the Scenario (2/2)
Failure Situation: SOAP Response with the server’s confirmation ofthe inventory update is lost due to a network failure
The client and server are left in an inconsistent state: The client(incorrectly) assumes that the request has not reached the server andsend it again although the server has successfully received andprocessed the message
Error-handling must be implemented on part of the InventoryManagement Server to detect duplicate messages sent by the client
Confirmation(SOAP/HTTP Response)
Mobile InventoryClient
InventoryManagement ServerInventory Counts
(SOAP/HTTP Request)
Web ServiceProvider
Web ServiceProvider
Web ServiceConsumer
Web ServiceConsumer
InventoryDatabaseUpdate
© SAP 2008 Page 16
Motivation for WS-Reliable MessagingConclusions from the Business Scenario
In scenarios that require reliable, once-only delivery of requests usingSOAP over plain HTTP, both the Web Service Consumer and theProvider must implement custom logic to ensure that
Requests already received by the Web Service Provider are not re-processed if submitted again by the Web Service Consumer
Duplicate requests are answered by the original response message toensure that the client gets a valid response to service invocations
Implementing this logic can be cumbersome andinteroperability with it is basically only possible betweencomponents based on this proprietary protocol
© SAP 2008 Page 17
OASIS Web Services Reliable Exchange(WS-RX) TC formed in May 2005 to continuedeveloping the “submitted” Web ServicesReliable Messaging (WS-RM) 1.0 specification
WS-RM 1.1 approved as an OASIS Standardin June 2007
Core concept of WS-RM is the Sequencethat effectively is a contract to reliably delivera set of messages
WS-RM core model and terminology
Supported version in SAP NetWeaver CE 7.1: WS-RM 2005/02
WS-Reliable Messaging (WS-RM) Overview
SOAP EnvelopeSOAP Envelope
SOAP Header
SOAP Body
Data
WS-RMHeader
SequenceLifecycleMessages
Sequence
SequenceAck
Web ServiceConsumer
Web ServiceConsumer
Web ServiceProvider
Web ServiceProvider
RMSource
RMSource
RMDestination
RMDestination
Send DeliverTransmit
Acknowledge
CreateSequence
TerminateSequence
WS-RM protocol elements:Header blocks and messages
…
© SAP 2008 Page 18
Each message delivered at least onceEach message delivered at most onceEach message delivered exactly once
Messages delivered in the same order they have been sent
M3
M2
WS-Reliable MessagingDelivery Assurance Options
Web ServiceConsumer
Web ServiceConsumer Web Service
ProviderWeb Service
ProviderIntermediaryIntermediary
IntermediaryIntermediary
IntermediaryIntermediary
M1
M2
M3
Web ServiceConsumer
Web ServiceConsumer
Web ServiceProvider
Web ServiceProvider
RMSource
RMSource
RMDestination
RMDestination
M1M2M3
M1
Send
Deliver
RMSource
RMSource
RMDestination
RMDestination
M1M1
M1M1M
1M1
Exactly Once Delivery Assurance
In-Order Delivery Assurance
Send
Deliver
© SAP 2008 Page 19
Sample WS-RM Protocol Message Flow
CreateSequence
CreateSequenceResponse (Id XYZ)
Sequence (Id XYZ, Message #1)
SequenceAcknowledgement (Id XYZ, Message #1)
TerminateSequence (Id XYZ)
Sequ
ence
Cre
atio
n an
dM
essa
ge T
rans
mis
sion
Sequ
ence
Term
inat
ion
1
2
3
5
8
Web ServiceProvider
Web ServiceProvider
Sequence (Id XYZ, Message #2)4
Sequence (Id XYZ, Message #2)6
TerminateSequenceResponse(Id XYZ)9
SequenceAcknowledgement (Id XYZ, Message #2)7
Web ServiceConsumer
Web ServiceConsumer
Message #2 inthe sequence is
lost in transit
Retransmissionof the
unacknowledgedMessage #2
© SAP 2008 Page 20
Summary
Major QoS requirements for Web Services are addressed by specificstandards for each domain
WS-Security is a rich framework to secure SOAP on the message layer
WS-Reliable Messaging provides delivery assurance for SOAPmessages based on the concept of a sequence
WS-Policy is a general purpose framework to expose a broad range ofservice requirements in a standardized and platform-independent manner
WS-SecurityPolicy and WS-RM Policy define the domain-specificrequirements for security and reliability as WS-Policy assertions
© SAP 2008 Page 21
Agenda
1. Secure and Reliable Web Services – A short primer on StandardsInteroperability and StandardsQuality of Service in SOA: WS-Security & WS-Reliable Messaging
2. Web Services Development in SAP NetWeaver CEApproaches in Web Services DevelopmentJava EE 5 Web Service tools in SAP NetWeaver Developer StudioWeb Services in Java EE
3. Configuring Security and ReliabilityDesign-time configuration in SAP NetWeaverRuntime configuration in SAP NetWeaverAutomating Web Service Consumer Configuration
4. Design- and Runtime Interoperability in Heterogeneous LandscapesConsuming a secure SAP Web Service in Microsoft .NET
© SAP 2008 Page 22
Approaches in Web Services Developmentusing SAP NetWeaver Developer Studio
Inside-Outalso called bottom-up orcode-firstexpose an existingimplementation (EJB sessionbean or POJO) as a Web Service
Outside-Inalso called top-down orcontract-firststart from a WSDL document of aservice and generate the codeskeleton of the implementation(EJB session bean)implement the business methodsof the generated session bean
Activate /Deploy Web Service
GenerateWeb Service
ImplementBusiness Application
Inside-OutApproach
1
2
3
Implement codeBackend
GenerateProxies
Define ServiceInterfaces
Outside-InApproach
RegisterWSDL
1
2
3
4
© SAP 2008 Page 23
Steps to Create an Inside-Out Web Servicefrom an Enterprise Java Bean
Create an EJB 3.0 project and add itto an existing Enterprise ApplicationProject
Create an EJB Session Bean for theWeb Service
1
2
© SAP 2008 Page 24
Steps to Create an Inside-Out Web Servicefrom an Enterprise Java Bean
3
4
Add a business method to theEJB 3.0 implementation bean andlocal/remote interface
Select the EJB implementation beanand choose Web Services CreateWeb Service
© SAP 2008 Page 25
Steps to Create an Inside-Out Web Servicefrom an Enterprise Java Bean
5
6
Specify the Web Services Wizardoptions
Optionally, select a ServiceEndpoint Interface that contains themethods of the implementationclass which you want to expose asa Web Service
© SAP 2008 Page 26
Steps to Create an Inside-Out Web Servicefrom an Enterprise Java Bean
7 Select the methods to expose inthe Web Service
The Developer Studio adds Java EE 5 annotations forWeb Services to the implementation bean
8
© SAP 2008 Page 27
Web Services in Java EE 5
Important concepts in Java EE 5:Annotations: Standard feature of theJava language since J2SE 5.0Dependency Injection: Programmingpattern to hide the creation and lookupof resources from the application‘s code
@Statelesspublic class OrderProcessingBean{
@EJBprivate MyBeanType myBean;...myBean.method();...
No more JNDIlookupsNo more XMLdescriptors
Web Service in Java EE 5:Simplified development of Web Service Providers and Consumersthrough annotations and dependency injectionIntegrated Web Services stack:
JAXB 2.0 (Java Architecture for XML Binding): Tools and API to generateJava Classes from XML Schema and marshal/unmarshal XML documents toJava objects and vice versaJAX-WS 2.0 (Java API for XML-based Web Services): Uses JAXB for all databinding and makes Web Services in Java easy to develop and to use
© SAP 2008 Page 28
JAX-WS by ExampleGenerated Annotations in the Demo
@WebService marks a Java class as implementing a Web Service
@WebService marks a Java interface as defining a Web Service interface@WebMethod customizes a method that is exposed as a Web Service operation@WebParam customizes the mapping of an individual parameter to a Web Service messagepart and XML element
@WebService(...)@Statelesspublic class OrderProcessingBean implements ...{public void submitOrder(Order order){...
© SAP 2008 Page 29
Agenda
1. Secure and Reliable Web Services – A short primer on StandardsInteroperability and StandardsQuality of Service in SOA: WS-Security & WS-Reliable Messaging
2. Web Services Development in SAP NetWeaver CEApproaches in Web Services DevelopmentJava EE 5 Web Service tools in SAP NetWeaver Developer StudioWeb Services in Java EE
3. Configuring Security and ReliabilityDesign-time configuration in SAP NetWeaverRuntime configuration in SAP NetWeaver (DEMO)Automating Web Service Consumer QoS Configuration
4. Design- and Runtime Interoperability in Heterogeneous LandscapesConsuming a secure SAP Web Service in Microsoft .NET
© SAP 2008 Page 30
Association of abstractQoS requirements withimplementation
components
Definition of abstractQoS requirementsindependent ofimplementationtechnology
Design-Time vs. Runtime Configuration
Business Expertdefines the functionalrequirementsunderstands the business-related QoS issuesknows about legalconstraints
Developerdesigns and implements thetechnical architectureis NOT a security expert per sehas to ‘translate’ or map thebusiness-level securityrequirements to the technicalarchitecture of the system
Domain Expertdoes NOT understand thebusiness - needs hintswhere to start!understands QoS-relatedtechnologies (e.g. security)in great detailis responsible to enforce apolicy
Requirements aretranslated or mapped
to concrete policies
Design-Time Runtime
The complexity of technical QoS settings is mitigated by starting withsimple, relatively abstract requirements at design time which arebound by an domain expert to concrete realizations at runtime
© SAP 2008 Page 31
Expressing QoS Requirements at Design-Timewith Code Annotations: Security (1/2)
@AuthenticationDTDefines the authentication behaviorfor a serviceLocation/Scope: class/binding onlyQualifiers: authenticationLevel
NONE
BASIC
STRONG
Does not enforce a particular authentication level, i.e. transport(HTTP/HTTPS) or message (WS-Security)
BASIC is fulfilled by– Transport Level: HTTP Basic Authentication (or stronger)– Message Level: WS-Security Username Token (or stronger)STRONG is fulfilled by– Transport Level: X.509 Client Certificate or SAP Logon Ticket– Message Level: WS-Security X.509 Token or SAML Token (Assertion)
© SAP 2008 Page 32
Expressing QoS Requirements at Design-Timewith Code Annotations: Security (2/2)
@TransportGuaranteeDTDefines the message protection requirementsLocation/Scope: class/binding onlyQualifiers: level
NONE
INTEGRITY
CONFIDENTIALITY
BOTH
Does not enforce a particular protection level, i.e. transport (HTTP/HTTPS) ormessage (WS-Security)
INTEGRITY is fulfilled by– Transport Level: HTTPS (SSL)– Message Level: Incoming Request – Require SignatureCONFIDENTIALITY is fulfilled by– Transport Level: HTTPS (SSL)– Message Level: Incoming Request – Require Encryption
© SAP 2008 Page 33
Expressing QoS Requirements at Design-Timewith Code Annotations: Reliability
@RelMessagingNW05DTOperation
Enables Web Services Reliable Messaging (WS-RM) for a Web ServiceLocation/Scope: method/operationPrerequisites to enable WS-RM:
Works only for Inside-Out Web ServicesThe (bean) method must be explicitly set to the one wayMessage Exchange Pattern (MEP) with the @Oneway code annotation, i.e. itMUST return void
© SAP 2008 Page 34
Using Reliable Messaging AnnotationsExamples
Code Sample RM-enabled
Comment
@Oneway()@RelMessagingNW05DTOperationpublic int MyMethod (intvalue)
Method does not return void
@RelMessagingNW05DTOperationpublic void MyMethod (intvalue)
@Oneway annotation ismissing
@Oneway()@RelMessagingNW05DTOperationpublic void MyMethod (intvalue)
© SAP 2008 Page 35
Runtime Configuration EnforcementA Sample Scenario (1/4)
Insert Design-Time Code Annotation to enforce QoSconfiguration at runtime
Deploy the annotated Web Service Implementation
1
2
© SAP 2008 Page 36
Runtime Configuration EnforcementA Sample Scenario (2/4)
In SAP NetWeaver Administrator (NWA), go to SOA ManagementBusiness Administration Web Services Administration tocreate and configure a new endpoint for your service
Search for the Service Definition. The Details tab shows theconfiguration settings according to the code annotations in the EJB
3
4
© SAP 2008 Page 37
Runtime Configuration EnforcementA Sample Scenario (3/4)
Switch to the Service Endpointstab and click on Create Endpointto create a new endpoint and servicefor the Service Definition
Under the Security tab, the settingsfor Authentication are pre-configured according to the levelchosen in the annotation
5
6
© SAP 2008 Page 38
Runtime Configuration EnforcementA Sample Scenario (4/4)
Trying to configure a serviceendpoint without anyauthentication mechanism failsdue to a mismatch with thedesign time configuration
After selecting a strong authentication mechanism (e.g. Message-based authentication with X.509 Client Certificate and inboundsignature), the newservice endpoint iscreated
7
8
© SAP 2008 Page 39
Cross-Platform QoS ConfigurationHow Does it Work Today?
Configuration of QoS parameters is carried out withplatform-specific tools
Exchange of QoS configurations across different platforms isdone manually and configured separately on each side
Web ServiceProvider
Web ServiceProvider
Web ServiceConsumer
Web ServiceConsumer
QoS ConfigurationIntegrity
Confidentiality
Reliability
-
Manual configuration of
Client QoS parameters
Platform APlatform A Platform BPlatform B
Integrity &Reliability
QoS Configuration-
@TransportGuaranteeDTlevel=INTEGRITY
@RelMessagingNW05DTOperation
© SAP 2008 Page 40
Cross-Platform QoS ConfigurationHow Could it be Automated?
Configuration of QoS parameters is still carried out with platform-specifictools, but can be exported or imported using a standardized, platform-independent format
Transformation of the standardized configuration format into the platform-specific QoS configuration is done on each platform
Web ServiceProvider
Web ServiceProvider
Web ServiceConsumer
Web ServiceConsumer
QoS ConfigurationIntegrity
Confidentiality
Reliability
-
Export of configuration intoplatform-independent format
Platform APlatform A Platform BPlatform B
Integrity &Reliability
QoSConfi-guratio
n Import of configuration and(semi)automatic configuration
platform-independentformat
QoS Configuration-
@TransportGuaranteeDTlevel=INTEGRITY
@RelMessagingNW05DTOperation
© SAP 2008 Page 41
Motivation for Web Services Policies
QoS-requirements must be specified in a standardized manner so thatConsumer and Providers in a heterogeneous SOA landscape can interactbased on the same understanding in an automated and scalable fashion
How does a service consumer know whichparts of a message must be protected (e.g.against eavesdropping by a third party)?
How does a service provider express itsQoS requirements in a way thatconsumers on any platform in a hetero-geneous SOA can understand them?
How are complex QoS configurations(e.g. multiple authentication optionsfor service consumers) expressed?
Web ServiceConsumer
Web ServiceConsumer
Web ServiceProvider
Web ServiceProvider
WSDL
Data TypesOperationsTransport Protocols
Web ServiceConsumer
Web ServiceConsumer
Web ServiceProvider
Web ServiceProvider
WSDL
Data TypesOperationsTransport ProtocolsQoS requirements
QoSMetadata
1
2
Simple Request
3
Advanced Requestfulfilling the Provider‘s
QoS requirements
12
Simple Web Services Scenario
Advanced Web Services Scenario
(Semi-)AutomaticQoS Configuration
© SAP 2008 Page 42
WS-Policy FrameworkOverview
WS-Policy 1.5 Framework standardized as a W3C Recommendationin September 2007Provides a general purpose model and corresponding syntax to describe the QoSrequirements or so-called policiesDefines a base set of constructs that can be used and extended by other WebServices specifications to describe a broad range of service requirementsSupported Version in SAP NetWeaver CE 7.1: 2004/09 (WS-Policy 1.2)
<wsp:Policy><wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<wsp:ExactlyOne>
<wsp:All>
WS-Policy Assertion A
WS-Policy Assertion B
WS-Policy Assertion A
WS-Policy Assertion C
WSDLQoS
Metadata
Policy ExpressionCollection of Alternatives
(„pick one“)
Policy AlternativeCollection of Assertions
(„do all“)
Policy AssertionDomain-specific
requirement WS-SecurityPolicy
WS-RM
Policy
© SAP 2008 Page 43
WS-Security PolicyOverview
WS-Security Policy 1.2 has been approved as an OASIS standard in July 2007It defines the WS-Policy Assertions for security features provided by WS-Security, e.g.
Security mechanism to provide the security (Security Binding Assertions)What parts of a message are being secured (Protection Assertions)Type of tokens to use to protect the message(Token Assertions)
Supported version in SAP NetWeaver CE 7.1: 1.2
<wsp:Policy><wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<wsp:ExactlyOne>
<wsp:All>
WS-Policy Assertion A
WS-Policy Assertion B
WS-Policy Assertion A
WS-Policy Assertion C
...<sp:AsymmetricBinding>
<wsp:Policy><sp:InitiatorToken>
<wsp:Policy><sp:X509Token sp:IncludeToken="AlwaysToRecipient"><wsp:Policy>
<sp:WssX509V3Token10/></wsp:Policy>
</sp:X509Token></wsp:Policy>
</sp:InitiatorToken>...
</sp:AsymmetricBinding>
Messages must be protectedusing an asymmetricencryption key pair
Properties of the securitytoken used to sent fromconsumer (initiator) toprovider (recipient)
Service accepts X.509certificates which must beincluded in the servicerequest
© SAP 2008 Page 44
Summary: End-to-End Definition of QoSRequirements in the Development Process
@xyzDTpublicclass
...{
Design-Time Runtime
Granularity
...<sp:AsymmetricBinding>
<wsp:Policy><sp:InitiatorToken>
<wsp:Policy><sp:X509Token …>
<wsp:Policy><sp:WssX509V3Token10/>
</wsp:Policy></sp:X509Token>
</wsp:Policy></sp:InitiatorToken>...
</sp:AsymmetricBinding>
Non-formalBusiness
Requirements
CodeAnnotations
Service EndpointConfiguration
(NWA)
Service EndpointMetadata (WS-Policy +
StandardizedAssertions)
+
-
WSDLQoS
Metadata
© SAP 2008 Page 45
Agenda
1. Secure and Reliable Web Services – A short primer on StandardsInteroperability and StandardsQuality of Service in SOA: WS-Security & WS-Reliable Messaging
2. Web Services Development in SAP NetWeaver CEApproaches in Web Services DevelopmentJava EE 5 Web Service tools in SAP NetWeaver Developer StudioWeb Services in Java EE
3. Configuring Security and ReliabilityDesign-time configuration in SAP NetWeaverRuntime configuration in SAP NetWeaverAutomating Web Service Consumer Configuration
4. Design- and Runtime Interoperability in Heterogeneous LandscapesConsuming a secure SAP Web Service in Microsoft .NET
© SAP 2008 Page 46
Advanced Web Services Standards Support inMicrosoft .NET
.NET 2.0 supports core Web Service standards, such as WSDL 1.1and SOAP 1.1/1.2Web Services Enhancements (WSE) for Microsoft .NET 2.0 is asupported add-on to Microsoft Visual Studio .NET and the Microsoft .NET 2.0Framework providing support for WS-Security and other advanced Web ServiceprotocolsWith .NET 3.0, these advanced Web Service protocols became an integral partof the .NET Framework, which is now called the Windows CommunicationFoundation (WCF, formerly known as ’Indigo’)
.NET 3.0.NET 3.0
.NET Application.NET Application .NET Dev.-Tools.NET Dev.-Tools
Windows(XP, Server 2003/R2, Vista, Longhorn)
Windows(XP, Server 2003/R2, Vista, Longhorn)
WCF(Indigo)
WPF(Avalon)
WCS(Infocard)
WWF(Workflow)
.NET 2.0 CLR, .NET 2.0 Base Class LibrariesASP.NET 2.0, ADO.NET 2.0, WinForms 2.0
© SAP 2008 Page 47
.NET WCF Bindings
Bindings define the Transport (e.g. HTTP), Encoding (e.g. TextMessage) and Protocol (e.g. Web Services) required to communicatewith the Service
WCF is shipped with predefined, System-Provided Bindings. TheseBindings can be configured declaratively
Developers can also create their own Custom Bindings with theWCF API that provide full control over the messaging stack when oneof the system-provided bindings does not meet the requirements of aconsumer or providerconstructed from threeelements
Transport
Encoder
Protocol(s)
HTTP Text Security ...WCF Binding
TransportTCPHTTPMSMQ...
EncodersTextBinary...
ProtocolSecurityReliability.NET...
© SAP 2008 Page 48
The Cross-Platform Test Scenario
The scenario will demonstrate interoperability on two levels:Design time interoperability (Step ): Automated generation of the WebService consumerRuntime interoperability (Step ): Secure exchange of Web Servicemessages based on open standards between different platforms
Web ServiceConsumer
Web ServiceConsumer
Microsoft .NET3.0/WCF
Microsoft .NET3.0/WCF
Web ServiceProvider
Web ServiceProvider
SAP NetWeaver CE 7.1SAP NetWeaver CE 7.1
WS EndpointConfiguration
WSDLWS-
Policy exposed as
WSEndpoint
(Generated)WS Client
Proxy
Imported at design timeand transformed to 1
1
2
2
.NET 3.0/WCFConfiguration
(Custom Binding)
© SAP 2008 Page 49
Copyright 2008 SAP AGAll 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 changedwithout prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
SAP, R/3, xApps, xApp, SAP NetWeaver, Duet, SAP Business ByDesign, ByDesign, PartnerEdge and other SAP products and services mentioned herein as well as their respective logos aretrademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned and associated logos displayed arethe trademarks of their respective companies. Data contained in this document serves informational 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 writtenpermission of SAP 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 of the SAP® product and is not intended to be binding upon SAP to any particular course of business, product strategy, and/or development. Please note thatthis document is subject to change and may be changed by SAP at any time without notice. SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant theaccuracy or completeness of the information, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind, either express orimplied, 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 limitationshall not apply 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 thesematerials and does not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pages.
Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher Form auch immer, ohne die ausdrückliche schriftliche Genehmigung durchSAP AG nicht gestattet. In dieser Publikation enthaltene Informationen können ohne vorherige Ankündigung geändert werden.
Einige von der SAP AG und deren Vertriebspartnern vertriebene Softwareprodukte können Softwarekomponenten umfassen, die Eigentum anderer Softwarehersteller sind.
SAP, R/3, xApps, xApp, SAP NetWeaver, Duet, SAP Business ByDesign, ByDesign, PartnerEdge und andere in diesem Dokument erwähnte SAP-Produkte und Services sowie diedazugehörigen Logos sind Marken oder eingetragene Marken der SAP AG in Deutschland und in mehreren anderen Ländern weltweit. Alle anderen in diesem Dokument erwähnten Namen vonProdukten und Services sowie die damit verbundenen Firmenlogos sind Marken der jeweiligen Unternehmen. Die Angaben im Text sind unverbindlich und dienen lediglich zuInformationszwecken. Produkte können länderspezifische Unterschiede aufweisen.
Die in dieser Publikation enthaltene Information ist Eigentum der SAP. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher Formauch immer, nur mit ausdrücklicher schriftlicher Genehmigung durch SAP AG gestattet. Bei dieser Publikation handelt es sich um eine vorläufige Version, die nicht Ihrem gültigen Lizenzvertragoder anderen Vereinbarungen mit SAP unterliegt. Diese Publikation enthält nur vorgesehene Strategien, Entwicklungen und Funktionen des SAP®-Produkts. SAP entsteht aus dieserPublikation keine Verpflichtung zu einer bestimmten Geschäfts- oder Produktstrategie und/oder bestimmten Entwicklungen. Diese Publikation kann von SAP jederzeit ohne vorherigeAnkündigung geändert werden.
SAP übernimmt keine Haftung für Fehler oder Auslassungen in dieser Publikation. Des Weiteren übernimmt SAP keine Garantie für die Exaktheit oder Vollständigkeit der Informationen, Texte,Grafiken, Links und sonstigen in dieser Publikation enthaltenen Elementen. Diese Publikation wird ohne jegliche Gewähr, weder ausdrücklich noch stillschweigend, bereitgestellt. Dies gilt u. a.,aber nicht ausschließlich, hinsichtlich der Gewährleistung der Marktgängigkeit und der Eignung für einen bestimmten Zweck sowie für die Gewährleistung der Nichtverletzung geltenden Rechts.SAP haftet nicht für entstandene Schäden. Dies gilt u. a. und uneingeschränkt für konkrete, besondere und mittelbare Schäden oder Folgeschäden, die aus der Nutzung dieser Materialienentstehen können. Diese Einschränkung gilt nicht bei Vorsatz oder grober Fahrlässigkeit.
Die gesetzliche Haftung bei Personenschäden oder Produkthaftung bleibt unberührt. Die Informationen, auf die Sie möglicherweise über die in diesem Material enthaltenen Hotlinks zugreifen,unterliegen nicht dem Einfluss von SAP, und SAP unterstützt nicht die Nutzung von Internetseiten Dritter durch Sie und gibt keinerlei Gewährleistungen oder Zusagen über InternetseitenDritter ab.
Alle Rechte vorbehalten.