GRC
HR
SCM
CRM
BI


Article

 

Taking SSO to the Next Level: SAP Supports User Identity Federation with SAML 2.0

by Dimitar Mihaylov and Yonko Yonchev | SAPinsider

July 1, 2010

Traditional SSO technologies boost user productivity and streamline the authentication process, but are hampered by some key limitations. SAML 2.0 standards for SSO can help you overcome these limitations with a more automated authentication process and identity federation capabilities. Learn how SAP will be supporting these standards through an upcoming enhancement package.
 

The benefits of single sign-on (SSO) technologies — including improved user productivity and a streamlined user authentication process — have been well explored. However, traditional SSO technologies can be subject to some key limitations:

  • Support for cross-platform or cross-business domain SSO often requires extensive additional customization, including dedicated resources for aligning user identity information.
  • User access paths to SSO-enabled enterprise applications tend to be rigidly defined. Users must go to one application and get an SSO token before they can access the business application they need.
  • Interoperable SSO across applications from different vendors comes with limited support and often requires customizations to the system’s user authentication components.
  • There is limited support for automated single log-out (SLO), a security feature used to invalidate open user sessions in all applications accessed over SSO when users log out of certain applications they visit.

These limitations often mean increased costs to enable applications for SSO, and they significantly reduce SSO’s promised user productivity improvements. However, enterprise software users can resolve these problems with SAML 2.0 capabilities, which enable a more automated authentication process and introduce identity federation abilities that help better manage user information.

SAP has been working on releasing support for the SAML 2.0 standard within SAP enterprise applications. Starting with the soon-to-be-released update of SAP NetWeaver Identity Management (SAP NetWeaver ID Management) 7.1, SAP’s support for SAML 2.0 will become a reality.

IdP and SP: The SAML 2.0 Foundation

Before we dive into the benefits of SAML 2.0, let’s take a closer look at the tools that make it possible. As we’ve discussed in a previous Security Strategies article1, there are two main components that enable SAML 2.0 — the identity provider (IdP) and the service provider (SP). SAP will soon be rolling out these components (see Figure 1).

Figure 1 Support for a SAML 2.0 SP is planned to be available with SAP Java and ABAP application servers (subject to release level); SAP’s implementation of the SAML 2.0 IdP will be licensed with SAP NetWeaver ID Management 7.1 and can be installed on an SAP NetWeaver 7.2 or higher Java application server

With an upcoming service package release for SAP NetWeaver ID Management 7.1, SAP customers will be able to license SAP’s SAML 2.0 IdP component. The IdP is an SAP NetWeaver Java 7.2 application, which, within a trusted SAML 2.0-enabled application user environment, is fully responsible for:

  • Establishing initial user identity via an authentication method such as user  IDs and passwords, Kerberos, or X.509 client certificates
  • Certifying the au thenticated user identity with a signed SAML 2.0 SSO token called an assertion

SAML 2.0 SSO-accepting functionality for the IdP-trusting end-user application content providers — called SAML 2.0 SPs — is planned for release later in the year with an SAP Business Suite 7.0 enhancement package for ABAP applications. The same SP functionality for Java applications has already been released with SAP NetWeaver Composition Environment (SAP NetWeaver CE) 7.2. Within a SAML 2.0 user-to-application access process, SPs are responsible for:

  • Verifying the assertion received from a trusted SAML 2.0 IdP and using it to identify access rights for user access
  • Providing the end user with the application resources needed to perform a business-oriented task over the software — for example, displaying a portal site or placing an order

Using standardized SAML 2.0 definitions, the user can also initially access the SP, which will automatically redirect the user’s web browser to a trusted IdP for user identification.

The SP is functionally decoupled from the IdP, but can physically reside on the same server instance as the IdP — which means that an SAP NetWeaver Java 7.2 server could potentially perform both IdP and SP roles. Such a configuration lets the IdP act as a proxy and enable access over SAML 2.0 to older SAP web applications by transforming a SAML assertion to an SAP logon ticket. SAP plans to support such configurations with  products based on SAP NetWeaver Java 7.2 and higher, such as SAP NetWeaver CE 7.2.

Identity Federation: The Next Evolutionary Level for SSO

With SAP’s support of SAML 2.0, companies will also be able to take advantage of identity federation capabilities. Identity federation refers to technical capabilities for enabling transparent user SSO among separate user administration domains that only optionally share user information.

Identity federation is a major evolution of the SSO concept of supporting use cases with limited sharing capabilities for user information and preserving user accountability and user access personalization. This means that you can enable users within your business partners’ domain to securely access data or systems in your company’s domain — without making your company responsible for maintaining and administrating the other companies’ users.

The SAML 2.0 standards enable several identity federation capabilities:

  • Out-of-band account linking — The profile accounts in the identity federation setup for user access are linked with a specific user attribute, which is pre-selected and pre-provisioned between the SAML 2.0 IdP and SPs. Different SPs may use different user profile attributes, including email addresses, Kerberos principle names, and the user logon IDs, to identify the user in the SSO process.
  • Persistent pseudonym account identifiers — With this type of federation agreement, SPs share no user profile information with the IdP. Rather, the user is identified from a common user identifier that the IdP and the SP agree upon. This identifier may be automatically generated by the IdP and then maintained in the SSO user’s SP profile (interactive federation) or centrally defined and provisioned via the SP and IdP’s local user identity management functions (out-of-band federation).
  • Transient pseudonym identifiers — In this case, the IdP and the SPs agree to only exchange user attributes rather than a user identifier. The IdP generates an assertion with pre-configured user profile attributes, and the SP calculates the group, authorization assignments, or the service user accessing its applications.

The out-of-band federation is particularly useful as a scalable alternative to maintaining user logon ID mappings, which used to be typical for enabling SSO. With SAML 2.0, administrators can maintain the range of access identifiers within the IdP component, which, in combination with SAP NetWeaver ID Management, will then be able to issue assertions with the correct user ID from the user profile.

The last two types of federation agreements are well suited to support seamless user access in business-to-business application scenarios. In such scenarios, for data privacy or competitive reasons, the two partners may prefer not to share user information. By deploying persistent or transient federation agreements, however, the two partners can still reap the benefits of transparent user access to applications across business domains, while minimizing or eliminating user identity information sharing.

Identity federation isn’t the only new benefit  customers will reap from SAP’s support of SAML 2.0. Those companies running SAP NetWeaver ID Management will also be able to combine their existing ID management processes with the authentication processes enabled by SAML 2.0.

Figure 2 Standardized deliverables of SAML 2.0

Enable Secure, Scalable SAP Application Scenarios

As we’ve discussed in previous Security Strategies columns, companies can now use SAP NetWeaver ID Management as a central hub for identity provisioning to SAP and non-SAP systems.5 Similarly, the SAML 2.0 IdP acts as a central hub for user authentication and the management of full user attributes for access to SAP and non-SAP SP end-user applications. Since the IdP component is planned for release with updates to SAP NetWeaver ID Management, companies will be able to take advantage of new user access scenarios that combine the functionality of both.

One example of such a scenario involves centralized user mapping. Consider a user with different logon IDs for various applications to which he has access. In the past, each SAP system and most non-SAP systems needed their own local user mapping information to map the user ID from the SSO token to the correct user.

Now, the information for these IDs and systems can be consolidated in SAP NetWeaver ID Management and made available to target applications over its classical user provisioning framework. And with the addition of the SAML 2.0 IdP, this mapping information can also be used to issue SSO tokens with the correct user ID for the specific SP application that the user is accessing. This means reduced TCO and a simplified configuration.

The combination of SAP NetWeaver ID Management and SAP’s IdP capability opens up completely new scenarios between business partners. The IdP functionality comes with standardized SAML 2.0 IdP proxy capabilities, which significantly reduce the effort required to establish trusts between SAML 2.0-enabled enterprise domains, each running their own IdP.

Consider a user from a partner company that has access to multiple applications from your partner-facing network. The trust relationship with this partner is established only between the SAP’s IdP proxy and the partner’s IdP. Combined with classical identity provisioning capabilities, this setup can enable ad hoc user provisioning between your organization and your partner to as many applications as needed (see Figure 3). The whole process of provisioning external users can then be managed with the approval workflow capabilities of the SAP NetWeaver ID Management Identity Center, ensuring compliance while automating and enforcing the application access process.6

Figure 3 Ad hoc user provisioning enabled by SAP’s IdP

Once the user is provisioned within your landscape, the partner’s IdP will then send its new authorization data within its SAML 2.0 assertion. Then, SAP’s IdP proxy will immediately update all local authorization assignments and ensure that the user is issued only appropriate SSO tokens.

As soon as the authorization assignments are updated within the landscape (users can do so through a manual approval workflow), the user will be automatically unlocked and notified via email. In this scenario, this step is done manually, but it could be configured to work automatically as well. In addition, SAML 2.0’s Manage Name Identifier protocol can enable user deprovisioning in such B2B scenarios.

A Look to the Future: SAP NetWeaver ID Management 7.2

SAP’s SAML 2.0 IdP release in SAP NetWeaver ID Management 7.1 will support identity federation and standardized SSO requirements for web-enabled applications that include direct end-user interaction from a web-enabled UI. However, the innovation will not end there.

With SAP NetWeaver ID Management 7.2, SAP plans to release a Security Token Service (STS) that will support user identity federation for web service applications, which complement applications with integrated UI capabilities.

With SAML 2.0 identity federation support across the end-to-end access path of enterprise application users, SAP customers will be able to reap user productivity benefits from efficient user identity focused application access, without compromising on accountability or content personalization requirements.

For more information on SAP’s SAML 2.0 capabilities, visit www.sdn.sap.com/irj/sdn/security.

Dimitar Mihaylov (dimitar.mihaylov@sap.com) works in SAP Labs Bulgaria as the development manager of the security and identity management department. His team is responsible for the development of the authentication, single sign-on and identity federation components in SAP NetWeaver. Dimitar Mihaylov received a M.Sc. degree in Computer Science from Sofia University (Bulgaria).

Yonko Yonchev (yonko.yonchev@sap.com) has been with SAP since 2004, working on a variety of security solution management topics, such as SAP user access control, single sign-on, web services and SOA security, and Java and portal server security. Yonko has an undergraduate degree in economics and an MBA with a management of information systems concentration from Bentley University. As of April 2010, Yonko joined the central product security governance team in SAP’s quality governance and production organization in Walldorf, Germany.

1 See “What’s in the Pipeline for SAP Security?” by Gerlinde Zibulski in the January-March 2010 issue of SAPinsider. [back]

2 For more information, visit http://help.sap.com/saphelp_nw70ehp2/helpdata/en/df/bedca2076511d7b84500047582c9f7/frameset.htm. [back]

3 The SAML 2.0 specifications, including an executive overview, are available from OASIS (www.oasis-open.org/committees/tc_home.php?wg_abbrev=security). [back]

4 To learn more, visit www.projectliberty.org/liberty/liberty_interoperable/implementations/saml_2_0_test_procedure_v3_2_2_full_matrix_implementation_table_q309. [back]

5 To learn more, see “Identity Management That’s Integrated into Your Current Business Processes“ by Regine Brehm and Jens Koster in the July-September 2009 issue of SAPinsider. [back]

6 For more information, see “Make Compliance a Seamless Part of Your Security Workflow“ by Regine Schimmer and Jens Koster in the April-June 2010 issue of SAPinsider. [back]

An email has been sent to:






More from SAPinsider



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!


SAPinsider
FAQ