User Administration & Authentication

User Management
SAP NetWeaver Portal uses the user management engine (UME) for user management. The
UME can be configured to work with user management data from multiple data sources, for
example, an LDAP directory, database of SAP NetWeaver Application Server (AS) Java, or AS
ABAP system.
The UME is integrated as a service of the AS Java. Therefore you can use the user management
tools of the AS Java to manage users.

Authentication
SAP NetWeaver Portal offers the same authentication mechanisms as
SAPNetWeaver Application Server (AS) Java.
Basic Authentication
This authentication mechanism is based on the Basic Authentication feature of the
HTTP protocol. When you configure the portal to use HTTP Basic Authentication as
authentication mechanism, authentication data is transported in clear text (base 64
encoded). This means that passwords can easily be read by an attacker with
physical access to the network path between the client and the portal server. The
attacker can then impersonate portal users. This is not a weakness of the portal
itself, but a weakness of the standardized HTTP Basic Authentication mechanism.
For this reason, we strongly recommend using Secure Sockets Layer (SSL) between
the client and portal server, since this encrypts all information exchanged between
client and server including the authentication credentials.
Integration Into Single Sign-On Environments

Single Sign-On
Single Sign-On (SSO) is a key feature of SAP NetWeaver Portal that eases user
interaction with the many component systems available to the user in a portal
environment. Once the user is authenticated to the portal, he or she can use the
portal to access external applications. With SSO in the portal, the user can access
different systems and applications without having to repeatedly enter his or her
user information for authentication.
The portal SSO mechanism is available in the following variants depending on
security requirements and the supported external applications:

 SSO with logon tickets

SSO with user ID and password
All variants eliminate the need for repeated logons to individual applications after
the initial authentication at the portal. Whereas SSO with logon tickets is based on a
secure ticketing mechanism, SSO with user ID and password forwards the users
logon data (user ID and password) to the systems that a user wants to call.
In most system landscapes, you set up the portal as the ticket-issuing system. This
means that users log on to the portal using any of the supported authentication
methods and the portal issues a logon ticket to the user. In cases where the portal is
not the ticket-issuing system, it is possible to set up the portal to accept tickets
issued by other systems.
Using Logon Tickets

When using logon tickets for authentication with Web applications, the user's ticket is stored
as a nonpersistent cookie in the user's Web browser. This cookie contains the information
necessary to log the user on to additional systems without having to provide explicit password
authentication. Therefore, you should protect the logon ticket from being compromised or
manipulated during transfer by using SSL between Internet-enabled components
Optionally, you can mark the logon ticket as a secure cookie, to enforce that the client browser
only sends the cookie over SSL connections. We strongly recommend this setting. For this, you
must set the user management property ume.logon.security.enforce_secure_cookie to TRUE.
To reduce the risk of malicious users reusing logon tickets in replay attacks, we recommend
that you reduce the validity period of the logon ticket. The default validity period is eight hours.
Using Logon Tickets with User Mapping
If users have different IDs in the portal and in ABAP-based systems, users and
administrators can map the users portal user ID to the users ABAP user ID in an
SAP reference system. By default, the mapped user IDs are stored encrypted in the
User Management Engine (UME) database. It is also possible to store the mapped
user IDs in an LDAP directory. In this case they are not encrypted. To prevent these
IDs from being manipulated, you must make sure that no unauthorized users have
write-access to the LDAP directory, in particular to the attribute containing the ABAP
user ID.
Using User ID and Password with User Mapping
When Single Sign-On with user ID and password is used, the user ID and password
are sent across the network. We strongly recommend that you protect the

connections to the back-end systems using HTTPS or SNC to prevent the user ID and
password being read by an unauthorized user.
Using Logon Tickets

When using logon tickets for authentication with Web applications, the user's ticket is stored
as a nonpersistent cookie in the user's Web browser. This cookie contains the information
necessary to log the user on to additional systems without having to provide explicit password
authentication. Therefore, you should protect the logon ticket from being compromised or
manipulated during transfer by using SSL between Internet-enabled components
Optionally, you can mark the logon ticket as a secure cookie, to enforce that the client browser
only sends the cookie over SSL connections. We strongly recommend this setting. For this, you
must set the user management property ume.logon.security.enforce_secure_cookie to TRUE.
To reduce the risk of malicious users reusing logon tickets in replay attacks, we recommend
that you reduce the validity period of the logon ticket. The default validity period is eight hours.
For more information about changing the validity period,
Using Logon Tickets with User Mapping
If users have different IDs in the portal and in ABAP-based systems, users and
administrators can map the users portal user ID to the users ABAP user ID in an
SAP reference system. By default, the mapped user IDs are stored encrypted in the
User Management Engine (UME) database. It is also possible to store the mapped
user IDs in an LDAP directory. In this case they are not encrypted. To prevent these
IDs from being manipulated, you must make sure that no unauthorized users have
write-access to the LDAP directory, in particular to the attribute containing the ABAP
user ID.
Using User ID and Password with User Mapping
When Single Sign-On with user ID and password is used, the user ID and password
are sent across the network. We strongly recommend that you protect the
connections to the back-end systems using HTTPS or SNC to prevent the user ID and
password being read by an unauthorized user.

Security Zones
Security zones control which portal components and portal services users can launch. They are
defined in the development phase. If a portal component or service is not assigned a complete
security zone in its descriptor file, the portal runtime assigns it to a predefined security zone
folder for unspecified components or services. The portal provides default permissions for the
standard security zone folders in which the portal applications shipped with the portals initial
content reside. These permissions provide a high level of security for a newly installed portal.
We recommend that you become familiar with the standard security zones created by SAP and

also the default permissions assigned to them. If necessary, adjust the default permissions to suit
your environment. We highly recommend that you use the SAP security zones structure for your
own content. You should make sure that the permissions on the security zones provide
appropriate protection against unauthorized access and adjust them if required.
Security zones control access to portal components whether they are accessed by a direct URL or
through a role-assigned iView based on that portal component.

UME Actions
UME actions are the UME equivalent of portal permissions. The UME verifies that users have
the appropriate UME actions assigned to them before granting them access to UME iViews and
functions. All other portal services do not use UME actions.
Network and Communication Security
The portal is dependent on SAP NetWeaver Application Server (AS) Java for network
communication. The portal network and communication security concept is covered
by the security concept for AS Java.

Network Architecture
The network architecture that you use depends on how sensitive the applications
and data are that you can access through the portal. Many different architectures
are possible. For a portal installation that requires a medium level of security or
higher, we recommend that you use an architecture with multiple network zones.
In this network architecture, the portal server and its underlying AS Java are located
in the inner demilitarized zone (DMZ). Any back-end systems such as SAP systems
are located in the high security area. User management engine (UME) data sources
such as a corporate directory server or an ABAP-based SAP system are also located
in the high security area. This setup ensures that by default, the inner DMZ systems
have a different subdomain and document domain from the high-security systems.
Smooth Web integration is guaranteed for systems in the inner DMZ.
The document domain determines when applications in different frames can
interact with each other. Document domains rely on the Same Origin Policy (SOP).
An application can only share information with another application if the DNS
domain name and protocol are identical. In SAP applications, the document domain
is relaxed by one level by default, that is, by removing the hostname from the fully
qualified hostname. With the relaxed document domain, applications can share
information between frames as long as the systems that they run on are in the
same subdomain. For example, host1.example.com and host2.example.com are in

the same relaxed document domain, example.com. The portal integration benefits
from the relaxed document domain by enabling features between different portal
frames, such as portal eventing, WorkProtect mode, session management, auto
resizing, and popup windows over iView borders.
For network architectures, which do not distinguish between an inner DMZ and a
high-security area, and therefore benefit from the smother portal integration
provided by the relaxed document domain, you must consider the security
requirements of the component systems. Document domain relaxing enables
applications on different hosts and in different frames to interact, but exposes the
applications to cross-frame scripting. If one of your back-end systems has
significantly higher security requirements, then you must determine if the benefits
provided by document domain relaxing outweigh the risk of scripting attacks by
malicious users. To mitigate the risk, you must either move the high-security system
to a different subdomain or disable document domain relaxing for applications on
the high-security systems. In addition to the portal features described above, you
may lose other functions, such as those provided by the BIApplicationFrame.
For more information about disabling document domain relaxing for and Web
Dynpro Java and Web Dynpro ABAP applications, see the following:

Data Storage Security

All data for SAP NetWeaver Portal resides in the database of SAP NetWeaver Application Server
(AS) Java. This includes the following:
All deployments, such as iViews, pages, and business packages
Portal objects, such as system landscape and security zone configurations
Activity reports
Portal roles
In addition, the portal makes use of data in the user management engine for identity and access
management.
The security of all data in the portal is covered by the security concept for the AS Java.

Operating System Security

If the underlying operating system of your portal installation is not sufficiently secured, attackers
can exploit existing vulnerabilities at operating system level. For this reason the operating
systems on all machines of your portal installation (Portal Server machine, persistence layer

machine, and so on) should be hardened. Hardening the operating system means to configure it
as securely as possible and includes the following:
Apply all available patches to the operating system before using it for the portal.
Deactivate or uninstall any service that is not needed for the operation of the portal.
Dispensable Functions with Impacts on Security
ActiveX Controls
The portal uses ActiveX controls to display content in the portal catalog. Since
security weaknesses in ActiveX controls can be exploited, you may wish to disable
them on your clients. By defining the corresponding settings on your clients and on
the portal server, you can deactivate ActiveX controls while still keeping the full
functionality of the portal.

Other Security-Relevant Information

Secure Installation
For Windows platforms, we recommend that you install SAP NetWeaver Application
Server (AS) Java and the portal on a different drive than the operating system. If
possible, no other software should be installed on the drive with the portal and the
AS Java. This is a defense-in-depth measure to reduce the impact of directory
traversal attacks for both the portal application and user-written iViews.

Trusted Software
Only install software on your portal from vendors and developers whom you trust.
Software from questionable sources can contain malicious code intended to harm or
compromise your system.

Logging and Tracing

The user management engine (UME) used by the portal logs important security events, for
example, user logon or changes to a users permissions.

Network Security
Your network infrastructure is an important element in protecting your SAP NetWeaver systems.
The network topology for the AS Java is based on the topology used by the SAP NetWeaver
platform.

SAP systems are implemented as client-server frameworks built in three levels: database server
level, application server level and the presentation level (front ends). The AS Java works at the
database and application levels in your implementation framework, where it defines and
forwards the presentation logic to Web client applications, such as, for example Web browsers
and Web Dynpro applications.
Data Storage Security
The AS Java provides a secure storage area where applications or service
components on the AS Java can store sensitive data such as passwords or
communication destinations, in encrypted form. Data saved in this area is encrypted
using a secret key that is created explicitly for the application or service component.

Secure Storage for Application Specific Data

Applications or application components, deployed on the AS Java, can save sensitive
data in encrypted form in a secure storage area in the AS Javas configuration
database. The data saved in this area is encrypted using a secret key that is created
explicitly for the application or service. The AS Java uses the triple DES algorithm to
perform the encryption.
You can use two approaches for storing and maintaining the encrypted data for the
individual applications or application components:

Centralized storage
With centralized storage, applications or application components use the Secure Storage service
on the AS Java to encrypt and decrypt the data. This data is also stored in the corresponding
secure storage context on the AS Java. You can control the parameters of this secure storage area
from the properties of the Configuration Manager.
Decentralized storage
With decentralized storage, the applications and application component maintain their own
storage area for the encrypted data. They only uses the Secure Storage service on the AS Java to
retrieve the key, which is necessary to encrypt and decrypt the data.
Integration
Applications or services can use the AS Javas Secure Storage service to encrypt and
store sensitive data such as passwords. To use the AS Java secure store, applications
or services are assigned a designated context area in the secure storage where the
corresponding encrypted data is stored.
To receive a context area, AS Java applications or services register with the secure
storage service. The first time an application or service requests access to secure

storage, the AS Java registers the application or service, creates a context for the
application or service, generates a secret key, and allows the application access to
the context for future requests.
Encryption of the state Field of JSF Pages
To ensure that client-side state is protected, we recommend that you encrypt the
state.