
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.
CommonAuthFlowsConfigurator configurator = new CommonAuthFlowsConfigurator(context);
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.
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();
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.
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.
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.
Add support for OTP authentication by setting the OTPConfigProvider to the CommonAuthFlowsConfigurator with the method supportOTPUsing(provider).You can invoke this method multiple times with different providers. During a conversation flow, the first provider that returns a non-null value is invoked.
<activity android:name="com.sap.smp.client.httpc.authflows.OTPAuthActivity"> </activity>
<intent-filter>
<data android:scheme="<<package name>>.xcallbackurl" />
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
</intent-filter>
HttpConversationManager manager = new HttpConversationManager(context);
CommonAuthFlowsConfigurator configurator = new CommonAuthFlowsConfigurator(context);
configurator.supportOTPAuthUsing(new OTPConfigProvider() {
@Override
public OTPConfig onOTPChallenge(IReceiveEvent event) {
return new OTPConfig(
"x-smp-authentication", "otp-challenge" “https://samlsdktesthmsdktenant.neo.ondemand.com/samlsdktest/ /mobileservices/OTPForm", " finished=true");
}
});
configurator.configure(manager);
manager.create(new URL(“<endpoint>”)).start();
The WebView appears repeatedly even when authentication is performed correctly by the end user. This may be because the cookies used during authentication are incorrect, which in turn causes the conversation flow to restart 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 OTP flow.