Integration in Single Sign-On Environments

Basic Authentication

Basic Authentication is an HTTP standard method for authentication, whereby the user provides a user ID and password for authentication. By default, the AS Java uses Basic Authentication for applications that are set up to use Basic or Form authentication.

For more information, see Logon Using User ID and Password on the AS Java .

Logon Tickets

The AS Java supports the use of logon tickets for SSO when using a Web browser as the front-end client. In this case, users can be issued a logon ticket after they have authenticated themselves against a ticket issuing system, with any of the supported mechanisms. The ticket can then be submitted to other SAP or non-SAP ticket accepting systems as an authentication token. The user does not need to enter a user ID or password for authentication but can access the system directly after the system has checked the logon ticket.

For more information, see Using Logon Tickets with AS Java .

Client certificates

As an alternative to Basic Authentication using a user ID and passwords, users using a Web browser as a front-end client can also provide X.509 client certificates to use for authentication. In this case, no passwords have to be transferred and the communication of user credentials is secured using the Secure Sockets Layer (SSL) Protocol. Authentication takes places without direct user intervention, which allows integration in a SSO environment.

For more information, see Using X.509 Client Certificates on the AS Java .

SAML Assertions

You can use SAML for SSO in a scenario where a user is authenticated on an external authentication system that acts as an SAML authority. Based on this authentication, the user receives an SAML assertion (upon request) that he or she can use to access the AS Java.

To protect the data exchange, SSL is required for the connection between the source and destination sites. SSL is required by the SAML specification, and by default its use is activated in the SAML configuration. However, for testing purposes, you can disable the enforcement of SSL for the SAML-based document exchanges.

The SAML Single Sign-On scenario involves a source site, assertion artifact and a destination site. The site that authenticates the user establishes a source site server that initiates the SAML communication. This source site provides the destination site with an assertion artifact, which is an identifier for the user's assertions. The source site also provides a responder, which acts as the SAML authority that actually provides the user's assertions. The destination site provides the desired resource and an artifact receiver, which receives the initial assertion artifact and passes it on to be evaluated by the SAML login module.

If the user's ID as provided by the SAML authority is not identical to the user ID at the destination site, then the destination site must also provide a user mapping mechanism.

Kerberos Authentication with SPNego

You can use the Simple and Protected GSS API Negotiation Mechanism (SPNego) to enable Kerberos authentication on the AS Java.

Kerberos is an integral part of the Windows 2000 and higher operating systems, however, you can integrate non-Windows server components into the Windows Integrated Authentication infrastructure. The SPNegoLoginModule of the AS Java enables you to use Kerberos independently of the underlying operating system (OS) of the AS Java host and without an intermediary Web server.

For more information, see Using Kerberos Authentication .

Single Sign-On for resource adapters

The AS Java provides an additional authentication mechanism type supported by the connector container: SAPAssertion Ticket of type com.sap.security.core.server.jaas.SAPAuthenticationAssertionTicketCredential. The SAPAssertion Ticket is fully compatible with the SAPLogon Ticket. With this authentication mechanism, you can specify additional authentication types in the deployment descriptor of the resource adapter according the J2EE Connector Architecture.

For more information, see Single Sign-On for Resource Adapters and JCA .

Header variables for user authentication

You can use header variable authentication to delegate user authentication to any external product, which authenticates the user and returns an authenticated user ID as part of the HTTP header. Users only have to authenticate once against the external product and can then access applications on the AS Java, such as the portal, with SSO.

When using an external product with the header variable login module for authentication, all requests must pass through the external product. In addition, the user ID that the external product returns in the HTTP header must exist in the user management data sources.

For more information, see Header Variables .