SNOTE Note Implementation

created by Deepika Paturu on Jun 6, 2013 11:33 AM, last modified by Deepika Paturu on Jun
6, 2013 2:47 PM
Version 2
inShare
Tweet
SNOTE is used for implementing the SAP notes in the system. SAP notes are small
corrections delivered by SAP before releasing the support package. All the SAP notes will be
included in the next support package release. The SAP notes which contain the correction
instructions can be implemented in the system using the SNOTE and there can FAQ notes
also which do not contain the correction instructions but are informative notes. The notes can
be edited by SAP after releasing to the customers and when the SAP note is edited by SAP,
new version of the SAP note will be released.

Few notes will be released to specific customers and they are called pilot release notes and
they will be accessible and can be implemented by only those customers.

Note Implementation :

Before implementing the note in the system, please read the note completing and understand
if it is valid for your system. Few notes contain the manual steps to be performed in the
system before implementing the note. Please check the note and implement the preimplementation steps manually in the system before implementing the note in the system and
post implementation steps manually after the implementation of the note.

Please refer the steps specified below for implementing the note in the system using SNOTE.

Goto Transaction SNOTE : Download SAP note enter note number

After downloading the note, please goto SAP NOTE browser ctrl+F9 and enter the note
number to check the implementation status of the note. The note can be implemented in the
system if the "can be implemented" status is available. Please click on Implement SAP Note
ctrl+F1 for implementing the note.

Different Implementation status available in SNOTE for particular SAP note downloaded in
the system.

Can be Implemented - Note is valid for your system release and support package level and
can be implemented in the system.

Cannot be implemented - Note is not valid for your system

Completely Implemented - The note is already implemented in the system

Incompletely Implemented - The note is partially implemented in the system and still some
correction instructions of the note need to be implemented in the system.

Obsolete - The note is already delivered with the support package implemented in the system.

Obsolete Version Implemented - Either newer version of the note is released by the SNOTE
or the system is upgraded to the higher version of the support package level.

The note log can be useful to check the implementation of the note and information about the
version and date and time of the note implementation in the system

Following are the two important notes which need to be implemented in all the system
depending on the basis releases. These notes contain the corrections for many known issues
with the SNOTE.

What Is an X.509 Certificate?

by Les Hazlewood on November 16 2011

Share on twitter Share on email Share on facebook Share on linkedin Share on
google_plusone_share

An X.509 certificate is something that can be used in software to both:

1. Verify a persons identity so you can be sure that the person really is who
they say they are.
2. Send the person who owns the certificate encrypted data that only they
will be able to decrypt and read.

To be fair, X.509 certificates can be used to do these things for more than just people - theyre
heavily used by software applications or computers to do this amongst themselves as well.
Anyway, just keep in mind when I say person in this article, it can mean any of these.
Lets look at these two use cases a little more closely.

Identity Verification
So weve said that an X.509 certificate can be used to verify a persons identity so you can
trust that they really are who they say they are.
In this use case, you can think of an X.509 certificate as similar to a national passport. And as
with national passports, you are very careful about who would ever have access to it - you
would never give your passport away to anyone else. It uniquely identifies you and only you.
Because of this uniqueness, the government uses passports to verify who you are - you
present it as a way of proving that you are a citizen of your country.
X.509 certificates act kind of like a digital passport of sorts - it contains information about
you and only you. And just as a national government acts as an authority for issuing and
validating passports, something similar, called a Certificate Authority (CA), exists for X.509
certificates.
A Certificate Authority is a 3rd party trusted by both you and anyone who might verify your
identity. That is, when you use your X.509 certificate with someone who needs to verify your
identity, you both trust that a certain Certificate Authority has validated your identity.
Because the 3rd party trusts that the CA verified you, they in turn trust that your X.509
certificate really represents you and only you.
There are well-known global and public Certificate Authorities, such as Verisign and
Digicert. But a Certificate Authority can also be any party that both you and the person
verifying you agree to as trusted. Many companies have their own private Certificate
Authorities used to verify employee identities, for example.

Securing your data

In addition to verifying your identity, X.509 certificates can also be used to secure data
intended for you so that prying eyes wont be able to see it. It does this via a mathematical
concept known as asymmetric key cryptography.

Asymmetric Key Cryptography

Asymmetric means, well, not symmetric of course, but for the purpose of this discussion, it
helps to think of asymmetric as not equal or similar. A key in this case is what you would
think it would be - something used to lock or unlock a protective barrier. So when put
together, asymmetric key cryptography basically means that one key is used to lock up data,
but an entirely different key is used to unlock the data.
Asymmetric Key cryptography is also known as Public/Private Key cryptography for this
reason: one of the two asymmetric keys can be freely given out to the world at large; anyone
can see and use it, which is why it is called the public key. The other of the two keys
however must remain totally private to you, so no one will ever see it or be able to use it. This
is naturally called the private key because it should remain private always.
The reason Public/Private Key cryptography works is that data locked by the public key can
only be unlocked by the private key and vice versa. If someone locks data with the public
key, no one else who has the public key can unlock it - not even the person that originally
locked it. Only the person with the private key can unlock the data. That is why the public
key can be given to and seen by anyone. As long as the private key remains safe, you can
rest assured the data is locked safely.
So if we had a public and private key, how would they be used?
As an example, lets say your bank wants to send you your bank account balance. Naturally
this is very sensitive information that should be for your eyes only. The bank can use your
public key to encrypt your bank account balance. The encrypted data can be safely emailed
directly to you (maybe as a file attachment), because it is all jumbled up and no one can
make sense of it (remember that public keys can not unlock data that was previously locked
with the same public key).
Because your private key is the only thing that can un encrypt (aka decrypt) the banks
email, you can use your private key to unlock the attached file and see your bank account
balance. Because no one else should ever have your private key, you can rest assured that
youre the only one who can see your bank account balance.

X.509 cryptography
Ok, great - we now know about asymmetric (public/private) key cryptography. What does
that have to do with X.509 certificates? Well, an X.509 certificate is composed of two chunks
of information:

1. Your identifying information, such as your name and maybe address

2. Your public key

As you can see, your public key is included in the X.509 certificate. This way, anyone who
gets your certificate can both verify your identity (via a Certificate Authority) and encrypt
data for your eyes only with the included public key.

Create an X.509 Certificate

Now that weve seen the benefits of having an X.509 certificate, how do you get one?
Anyone can create their own X.509 certificate. Just know that until it is verified by a
Certificate Authority (like Digicert or Verisign or your companys own CA), most people
wont trust it or use it. But we can list the process of creating your own and having a CA
verify it.
Here is the high level overview of how one would create a validated X.509 certificate:
1. Using a cryptographic software tool (such as OpenSSL, the Java keytool,
etc), a user generates a cryptographic public/private key pair and of
course keeps the private key very secret (known to himself only).
2. Using their software tool, the users public key and an X.500 hierarchical
name identity, called a Distinguished Name are bundled up together into
an intermediate file called a certificate. This certificate is not considered a
valid X.509 certificate yet. Well get to that.
3. The user then encrypts this certificate using their private key which results
in a new file called a Certificate Signing Request or CSR. If you look
inside this file, youll see BEGIN CERTIFICATE REQUEST and END
CERTIFICATE REQUEST lines sandwiching a Base 64-encoded blob.
4. The user then submits this CSR file to a Certificate Authority (Digicert,
Verisign, etc) along with his public key (so the CA knows how to decrypt
the CSR).
5. The CA decrypts the CSR using the users public key which results in the
intermediate certificate from step #2 that contains the users
Distinguished Name and the users public key.
6. The CA verifies the identity of the user associated with the CSR. They will
ask for faxed identification of some sort - a national ID, a drivers license,
passport, etc.
7. Once the CA is happy that they have verified the users identity, they take
the intermediate certificate and encrypt it with their own private key which results in a new file. If you look inside this file, youll see BEGIN
CERTIFICATE and END CERTIFICATE lines sandwiching a Base 64encoded blob. This file is what is known a valid X.509 certificate.

8. The CA sends this newly created X.509 certificate back to the person who
was verified.

After this final step, the user has their validated X.509 certificate that they can use as
necessary.

Configuring HTTPS at Transport Level

with X.509 Certificate Authentication
Use
The AS ABAP and AS Java technology stacks of SAP NetWeaver also enable you to
configure Web service (WS) access authentication at the HTTP transport level using X.509
client certificates. For this access scenario, the AS ABAP or AS Java authenticate the WS
access with the underlying SSL security protocol.
You use the SAP NetWeaver Administrator (NWA) tool to configure both the AS ABAP and
AS Java systems for using transport level authentication with X.509 client certificates.
Prerequisites

To use X.509 client certificates for WS consumer authentication on the AS Java you
also have to enable the use of SSL on the AS Java and the AS ABAP. More
information: Using SSL on the AS Java and Using the Secure Socket Layer Protocol
with the AS ABAP.

Procedure
1. Configure a WS Service Endpoint for Providing a Web Service
1. In SAP NetWeaver Administrator, choose SOA Management Application and
Scenario Communication Single Service Administration Service Definitions .
2. Find the service for the service endpoint that you want to configure, and select it.
3. On the Configumation tab page, select the service endpoint to be configured.

4. Choose the Security tab page and switch to change mode.

5. Under Transport Protocol, select the HTTPS option.
6. Under HTTP Authentication, check the X.509 Client Certificate checkbox to permit
Single Sign-On with X.509 client certificates for WS consumers.
2. Configure a WS Port for Consuming a Web Service
1. In SAP NetWeaver Administrator, choose SOA Management Application and
Scenario Communication Single Service Administration Consumer Proxies .
2. Find the service for the service endpoint for which you want to configure a logical
port, and select it.
3. On the Configumation tab page, select the logical port to be configured.
4. Choose the Security tab page and switch to change mode.
5. Under Authentication, choose the HTTP Authentication option, and the X.509 Client
Certificate radio button.
6. Use the Details button to
o For an AS Java:

choose the PSE and the private key corresponding to the X.509 client
certificate to use for consuming the WS.

Configure mutual authentication using SSL with the SSL server

certificate options

o For an AS ABAP:

choose the PSE and the private key corresponding to the X.509 client
certificate to use for consuming the WS.

Authentication at SOAP Message Level

Use
With authentication at SOAP message level, the WS authentication data is transported with
token profiles in the SOAP message header. With this approach, the authentication takes
place at SOAP level, which allows the customizing of authentication and Single Sign-On
(SSO) to meet the specific security requirements for Web services.
The mechanisms supported by SAP NetWeaver for authentication at SOAP message level and
SSO are based ont he WS-Security standard. The WS-Security standard describes the

standard XML syntax with which authenticaiton data is included in the SOAP header, and
allows the interoperability of security between WS-supported systems that are based on
different programming languages.
Security Aspects
With authentication at SOAP message level, you can use end-to-end authentication that is
adjusted to the security requirements of the WS communication. With SAP NetWeaver, you
can use multiple types of WS authentication mechanisms at document level and strong
message authentication options based on WS-Security, such as XML signatures, XML
encryption, SOAP message age, and error reports.

Authentication at message level is customized to the specific security requirements

for Web services, which only require the protection of some of the security aspects
during the authentication and SSO process. The use of XML signatures allows you,
for example, to permit access to SOAP messages for intermediary WS systems and
therefore to ensure integrity, that is, to ensure that the message is not modified during
its transfer.

Authentication at message level on its own does not offer a point-to-point solution to
protect the overall security of the WS interactions between systems. However, the
reliability of SOAP messages at the lower level of the HTTP connection protocol
allows you to extend the security at SOAP level with security solutions at HTTP
transport level. You can, for example, use HTTPS as a protected connection channel
that uses the SSL security level for transport level security.

WS SecureConversation

http://help.sap.com/saphelp_nwpi711/helpdata/en/48/aea404ac5a3206e10000000a42189c/co
ntent.htm

This standard specified by OASIS for Web Services security describes how signatures and
encryption are used to protect SOAP messages with X.509 certificates. With the defined
security mechanism, a consumer can send a signed and encrypted message to a recipient. He
or she uses the public key of the server to encrypt and the private key of the client to sign.
WS SecureConversation

Secures SOAP communication over HTTP for Web Services

Defines how the provider and consumer communicate without using asymmetric
encryption, since symmetric encryption saves time

Ensures unbroken communication, since the key is in the SOAP header (there is no
need, for example, to interrupt communication with a reverse proxy)

Defines how a security context can be set up and shared and how to derive session
keys

If not only one, but rather a number of messages are exchanged, it is more efficient for the
communication partners to build and share a security context. Also, only public-key
cryptography is used to negotiate symmetric keys.
SecureConversation can be created using SSL or asymmetric signature and encryption or
using symmetric signature and encryption.
More information: WS Security XML Signature/Encryption
SAP is initially using the security context primarily to allow WS-ReliableMessaging to reuse
a security context, so that the server can contact the client.
Prerequisites

To use WS-SecureConversation, the following requirements must be met: No additional

configuration is required.

To use WS-Security XML signatures and encryption with X.509 certificates, you need
to enable the use of cryptographic functions for the AS ABAP system. More
information: Digital Signatures and Encryption

The corresponding option is selected in the configuration (for example, in

SOAMANAGER).

Both the consumer and provider systems have an SSL trust relationship.
More information:
o

Configuring the AS ABAP for Supporting SSL

Configuring the Use of SSL on the AS Java