Single Sign-On (SSO) is a key feature of the 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 user’s logon data (user ID and password) to the systems that a user wants to call.
In most system landscapes, the portal is set up 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.
For more information on Single Sign-On in the portal, see:
? When using logon tickets for authentication with Web applications, the user's ticket is stored as a non-persistent 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 an explicit password authentication. Therefore, you should protect the logon ticket from being compromised or manipulated during transfer by using SSL between Internet-enabled components. See Transport Layer Security.
? 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 logon tickets being reused in replay attacks, we recommend that you reduce the validity period of the logon ticket. The default validity period is eight hours. To change the validity period, use the user management configuration tool in the portal.
If users have different IDs in the portal and in ABAP-based SAP systems, users and administrators can map users’ portal user ID to their ABAP user ID in a 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. See also Using an LDAP Directory Attribute as the ABAP User ID.
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 backend systems using HTTPS or SNC to prevent the user ID and password being read by an unauthorized user.
We strongly recommend that you install the full version of the SAP Java Cryptographic Library if you use user mapping. This toolkit is required so that user mapping data can be stored in encrypted form. If the toolkit is not deployed, user mapping data is stored with weak encryption (base 64 encoding), which is not recommended for production systems.