Show TOC

Support for Common Authentication and Authorization FlowsLocate this document in the navigation structure

The HttpConversation library with its filter mechanism makes a conversation flow possible by allowing controlled implementation of scenarios that involve authentication and authorization. The HttpConvAuthFlows library used with HttpConversation lets you manage common authentication/authorization flows, for example, Basic authentication and SAML flow. A manager configurator called CommonAuthFlowsConfigurator lets you configure your HttpConversationManager to manage the authentication/authorization flow of its conversations.

To utilize the CommonAuthFlowsConfigurator, obtain an instance by using its constructor that expects an application context:
CommonAuthFlowsConfigurator configurator = new CommonAuthFlowsConfigurator(context);
Basic Authentication

You can add support for Basic authentication by setting a specified UsernamePasswordProvider to the CommonAuthFlowsConfigurator using the supportBasicAuthUsing(provider) method.

The supportBasicAuthUsing(provider) method enables usage of IBasicAuthCredentialsObserver objects: if a conversation manager is configured using a configurator of this type, supporting basic authentication and that manager is then extended with IBasicAuthCredentialsObserver objects. After which these observers are invoked. This method can be invoked multiple times with different providers, each placed in a list. During a conversation flow, the first provider that returns a non-null value (which can be either a username/password combination or a cancellation object) is invoked.

Credentials can be provided either in the implementation of UsernamePasswordProvider, or in response to a challenge from the corresponding onCredentialsNeededUpfront() and onCredentialsNeededForChallenge() methods. Credentials are expected to be provided by returning a UsernamePasswordToken instance from these methods, not from being stored within the manager context.

The code below provides credentials for an authentication challenge with the help of the CommonAuthFlowsConfigurator. Credentials are provided by UsernamePasswordProvider because onCredentialsNeededUpfront() returns null. onCredentialsNeededForChallenge() returns the expected UsernamePasswordToken..
Sample Code
HttpConversationManager manager = new HttpConversationManager(context);
CommonAuthFlowsConfigurator configurator = new CommonAuthFlowsConfigurator(context);
configurator.supportBasicAuthUsing(new UsernamePasswordProvider() {
	@Override
	public Object onCredentialsNeededUpfront(ISendEvent event) {
		return null;
	}
	@Override
	public Object onCredentialsNeededForChallenge(IReceiveEvent event) {
return new UsernamePasswordToken(userName, password);
	}
});
configurator.configure(manager);
manager.create(new URL(“<endpoint>”)).start();
SAML2 Flow

Add support for SAML2 authentication by setting the SAML2ConfigProvider to the CommonAuthFlowsConfigurator with the method supportSaml2AuthUsing(provider). You can invoke this method multiple times with different providers, using a list. During a conversation flow, the first provider that returns a non-null value is invoked.

You must implemnet the SAML2ConfigProvider to supply SAML configuration parameters when they are required. The implementation is expected to return an instance of the SAML2Config from the onSAML2Challenge() method. Failing to provide a configuration object cancels the conversation; SAML2AuthCancellation is the cancellation object.

The SAML2Config constructor has these parameters:
  • header (optional) The server HTTP response header name that indicates the SAML challenge, and facilitates SAML challenge detection if the server supports the sending of this header.
  • finish endpoint The URL the client must send the request to start the SAML authentication.
  • finish endpoint parameter The URL parameter that detects flow completion.

Add the SAML2AuthActivity to the Android Manifest before using SAML2 this way. SAML2AuthActivity shows a WebView whenever browser-based authentication is required.

Use the SAPCookieManager, since the cookies received by the WebView are used in the native HTTP communication as well.

This code illustrates how to use the CommonAuthFlowsConfigurator to configure the manager to process the SAML2 flow.
Sample Code
HttpConversationManager manager = new HttpConversationManager(context);
CommonAuthFlowsConfigurator configurator = new CommonAuthFlowsConfigurator(context);
configurator.supportSaml2AuthUsing(new SAML2ConfigProvider() {
	@Override
	public SAML2Config onSAML2Challenge(IReceiveEvent event) {
		return new SAML2Config(
"com.sap.cloud.security.login", “https://samlsdktesthmsdktenant.neo.ondemand.com/samlsdktest/SAMLAuthLauncher", "finishEndpointParam");
	}
});
configurator.configure(manager);
manager.create(new URL(“<endpoint>”)).start();

The WebView appears repeatedly even when authentication is done correctly by the end user. This may be because the cookies used during authentication are incorrect, which in turn causes the conversation flow to be restarted repeatedly until the maximum number of restarts is reached. To troubleshoot this, and other issues, turn on the DEBUG log level and use an HTTP traffic logging tool such as Fiddler to capture the network data exchanged (including cookies).

If more conversations are started in parallel,even using different HttpConversationManagers, which has one common finishEndpoint, the WebView appears only once and after a successful authentication, all initiated conversations continue simultaneously with their SAML flow.