Single Sign-On 

SAP NetWeaver offers several mechanisms for authenticating users. If you have many systems in your system landscape, then a single sign-on (SSO) environment can help to reduce the number of passwords that users have to remember. For detailed information, see User Authentication and Single Sign-On.

SAP NetWeaver Portal provides two variants for enabling SSO depending on security requirements and the supported external applications:

●      SSO with logon tickets

●      SSO with user ID and password

In the portal environment, SSO eases user interaction with the many systems, components, and applications available to the user. Once the user is authenticated to the portal, he or she can use the portal to access the different systems without having to repeatedly enter his or her user information for authentication. For general information on SSO in the portal, see Portal Authentication Infrastructure.

Apart from logon tickets and user mapping, you can integrate other third-party SSO authentication methods into certain points within your landscape.

 

SSO in a Federated Portal Network

In a federated portal network, the following should be noted:

●      Communication between a producer portal and a consumer portal requires the use of logon tickets for SSO.

●      To facilitate acceptance of the logon ticket between a producer portal and a consumer portal, you need to set up trust between the portals. For more information, see Setting Up Trust.

●      To facilitate SSO authentication between the client and a consumer portal, you can use logon tickets or other forms of authentication, such as X.509 client certificates, SPNego, and SAML.

SSO between all portals and portal applications use logon tickets. Therefore, if you are using alternative forms of SSO authentication between clients and a consumer portal, you still need to ensure that login module stacks for SSO include login modules for ticket evaluation and creation. You do this by either adjusting the login module stacks for AS Java applications or the authentication schemes for the portal iViews that users request access to. For more information, see Authentication Mechanisms and Single Sign-On Integration. See also Integration in Single Sign-On (SSO) Environments.

●      To facilitate client-to-backend and producer-to-backend SSO authentication, you can use logon tickets or other forms of SSO, such as user mapping. For more information, see Destination Service.

If any applications on the producer portal retrieve data from a secure back-end system and logon tickets are used for SSO, then you need to set up trust:

■       Between the producer portal and the back-end system

■       Between the consumer portal and the back-end system

For information about setting up trust between SAP NetWeaver Portal and a SAP system, see Configuring the AS Java to Accept Logon Tickets.

●      Working with producers and consumers in the same domain is strongly recommended. Working across multiple domains has inherent security risks, and certain applications may have problems with client eventing since JavaScript policies restrict cross-domain scripting.

Setting up a federated portal network across multiple domains requires the use of SSO with logon ticks. For more information, see:

○       How To Set Up the Landscape for a Federated Portal Network guide. Available on SAP Developer Network at sdn.sap.com/irj/sdn/howtoguides → SAP NetWeaver 7.0 → User Productivity Enablement → Running an Enterprise Portal.

○       Logon Tickets for Multiple Domains 

●      In the remote role assignment and remote delta link modes, only one logon ticket is issued by the consumer portal. The consumer portal creates the logon ticket and forwards it to the client (user). The ticket is then sent by the client's browser to the producer portal.

SSO with Remote Role Assignment and Remote Delta Link

Logon tickets and trust configurations enable single sign-on and allow the seamless flow of data between the client's browser, the consumer portal, and the producer portal at runtime.

From an SSO perspective, the remote role assignment and remote delta link modes have the same requirements. Minor technical differences exist with the overall runtime flow between client, producer, and consumer. For example, in remote role assignment, the consumer portal requests the navigation structure and framework for a remote role from the producer portal. In remote delta link mode, this does not happen.

The following figure illustrates an authentication and data flow for remote role assignment:

...

       1.      The client's browser contacts the consumer portal.

This flow assumes the user has already logged on to the portal. Other forms of authentication that are not based on logon tickets are permitted for initial logon only. In such cases, a session-based logon ticket must be issued as well, which is required for most post-logon interactions.

       2.      The consumer portal requests the navigation structure and framework for the remote role from the producer portal. The trust configuration between the consumer and producer allows the same session-based logon ticket to be used for SSO authentication.

       3.      The navigation properties from the previous request are sent back to the consumer portal.

       4.      The consumer portal builds a navigation structure and creates new URLs (referencing the producer portal directly) for content assigned to the role.

       5.      The consumer sends the role navigation structure and redirected URLs back to the client's browser.

       6.      The client's browser requests the content directly from the producer portal.

       7.      The producer generates and renders the iView markup and sends it to the client's browser to be displayed in the portal runtime.

In cases where an iView or application retrieves its data from a data source, such as a back-end system or the Web, the type of iView determines if the client accesses the data source directly (for example: SAP application iViews, URL iViews, and Web Dynpro ABAP iViews) or through the producer portal (for example: Web Dynpro Java iViews).

The trust defined between the producer, the consumer, and back-end systems allows SSO authentication to succeed using the client's logon ticket. Other means of SSO can be used to authenticate the user with secure back-end systems.

SSO with WSRP Application Sharing

One of the differences WSRP application sharing and the other content is that the client's browser never accesses the producer portal directly.

The following figure illustrates an authentication and data flow for WSRP application sharing between two NetWeaver portals:

...

       1.      The client's browser contacts the consumer portal.

This flow assumes the user has already logged on to the portal. Other forms of authentication that are not based on logon tickets are permitted for initial logon only. In such cases, a session-based logon ticket must be issued as well, which is required for most post-logon interactions.

       2.      The consumer portal processes its local proxy-to-portlet iViews and sends requests to the producer portal for all corresponding applications rendered by iViews. The trust configuration between the consumer and producer allows the same session-based logon ticket to be used for SSO authentication.

       3.      Rendered iViews are sent back to the consumer portal.

       4.      The consumer portal generates and renders the navigation structures and iView markup.

       5.      The consumer portal sends the rendered markup to the client's browser to be displayed in the portal runtime.

In cases where an iView or application retrieves its data from a data source, such as a back-end system or the Web, the type of iView determines if the client accesses the data source directly (for example: SAP application iViews, URL iViews, and Web Dynpro ABAP iViews) or through the producer portal (for example: Web Dynpro Java iViews).

The trust defined between the producer, the consumer, and back-end systems allows SSO authentication to succeed using the client's logon ticket. Other means of SSO can be used to authenticate the user with secure back-end systems.

 

User Mapping in a Federated Portal Network

User mapping is a form of enabling SSO, which provides logon data per data source from the portal. The system administrator responsible for configuring the necessary systems in the portal must define for each system if a user administrator, end user, or both perform the user mapping for each system object. The delegation of tasks depends on the nature of the data source. For more information, see Accessing Back-End Systems with a Different User ID.

In a federated portal network, user mapping can be used to create shortcuts between a user on the consumer and a system defined on a producer portal. User mapping cannot be used to map one user on a consumer portal to another user on a producer portal—the same user must be defined per individual throughout the network.

●      If an administrator is responsible for setting up the user mapping, this must be done directly on the producer portal. User administrators cannot set up user mapping on the consumer portal because the systems on which the remote iViews are based are not exposed on the consumer portal.

Administrators can make user mapping assignments in the portal using the User Administration → Identity Management interface. Assignments can be made on the level of single users, groups, or entire roles.

●      If business users are responsible for setting up their own user mapping to remote back-end systems, then they must do so on the consumer portal, even though the systems are located on the producer portal. Users must use the Personalization → User Mapping (Remote iViews) interface in the portal.