Custom SSO Mechanism Samples

Custom single sign-on (SSO) mechanisms provide a flexible way for customers to construct HTTP headers and cookies to send to the back end. Typically, you configure a custom SSO mechanism to support custom SSO schemes. The SAP Mobile Platform administrator who configures a back-end endpoint must understand how that back-end system processes SSO requests.

Custom Cookies and Headers

Custom cookies and headers enable SAP Mobile Platform to send one or more HTTP headers or cookies to the back end. An SAP Mobile Platform administrator can define a cookie or header with a name and a pattern. A pattern can be a constant value, a named credential, or a method expression.

Constant value – in this example, SAP Mobile Platform Server sends an HTTP request to the back end with the header Authorization: Basic cc21wQWRtaW46czNwQWRtaW4=
```
Name: Authorization, Pattern: Basic c21wQWRtaW46czNwQWRtaW4=, Type: Header
```
Named credential – this example is a generalization of an the existing SSO2 mechanism. When an administrator defines a custom cookie with the name MYSAPSSO2, and the pattern ${MYSAPSSO2}, the results are the same as the SSO2 mechanism. The pattern string is a placeholder, similar to a variable. At runtime, SAP Mobile Platform Server searches for a credential with a name that matches the pattern string, gets its value, and substitutes it for the pattern string.
```
Name: MYSAPSSO2, Pattern: ${MYSAPSSO2}, Type: Cookie
```
The following example has the same effect as using the existing X.509 SSO mechanism:
```
Name: SSL_CLIENT_CERT, Pattern: ${java.ssl.SSL_CLIENT_CERT}, Type: Cookie
```
Method expression – SAP Mobile Platform Server tries to execute the method at runtime. If successful, the server substitutes the pattern with the value that is returned by the method invocation, in this example, Negotiate 89a8742aa8729a8b028
```
Name: Authorization, Pattern: Negotiate ${spnego.getTicket(app1Realm, app1Service)}, Type: Header
```

SiteMinder Sample

If a back-end system is protected by a SiteMinder Web agent, an SMSESSION cookie can provide the SSO that is required. You can configure the HTTP/HTTPS Authentication provider in various ways to validate or obtain an SMSESSION cookie, which the provider can attach to the JAAS Subject as a NamedCredential, and forward to the back end. For example:

Name: SMSSESSION, Pattern: ${SMSESSION}, Type: Cookie

In this example, SAP Mobile Platform Server searches the NamedCredential type credentials attached to the JAAS Subject to find one with a name that matches the pattern string, and substitutes it into the pattern string as the value to send to the back end, in this case, a cookie named "SMSESSION". This is a more flexible way of sending custom SSO material than in prior SAP Mobile Platform versions.

OAuth Authentication Sample

If the HTTP/HTTPS Authentication provider can access an identity management (IdM) system, the HTTP/HTTPS Authentication provider can send client credentials to the IdM, which authenticates the client and returns an SSO token as a cookie; the HTTP/HTTPS Authentication provider can then save the token as a NamedCredential. The SSO token may be an OAuth token, which is part of a standard SSO mechanism that is rapidly gaining acceptance.

OAuth authentication can reuse the HTTP/HTTPS Authentication header that is already being used for Basic and Kerberos authentication, but it must look like Authentication: Bearer <OAuth token in base-64>.

Name: Authorization; Pattern: BEARER ${oauthToken}, Type: Header

In this example, accessing the back end using SSO via OAuth requires that you save the OAuth token that is sent back to the HTTP/HTTPS Authentication provider as a credential named "oauthToken."