[Last Update 2024.03.01]
Hello fellow SAP security enthusiasts!
I wanted to share some exciting news with you. I've been busy creating a couple of LinkedIn blogs that delve into the fascinating world of the SAP Secure Login Service for SAP GUI. As I was exploring this topic, I thought, why not bring all this valuable knowledge together into one comprehensive blog post?
I hope you enjoy reading it as much as I enjoyed writing it!
TOC
Introduction
Multiple Factors Propel SAP's Move Towards New Solution for Enhanced Authentication
Brief Overview of the SAP Secure Login Service for SAP GUI
Background
Embracing Change: Switching from Active Directory to Native Azure AD Environments
Ramifications on SAP Authentication Landscape
The Migration to Azure AD
The Exodus of Kerberos
Introducing Azure Active Directory Domain Services
The Implications for SAP GUI
HTTP-Driven SAP Applications and SAML 2.0
Exploring the SAP Secure Login Service for SAP GUI: An In-Depth Review
Basic Setup of the Service (SAP BTP & IAS)
Customization Options for X.509 DN in Issued Certificates
Certificate Chain of the SAP-Managed PKI
Aspects and Some Nice Features of SNC User Mapping
What's Still Missing and What Could Come Nex
Compilation of frequently asked questions
Introduction
The highly anticipated SAP Secure Login Service for SAP GUI has emerged as a testament to innovation, merging the stalwart functionality of the esteemed SAP Single Sign-On with the expansive capabilities of cloud computing.
On May 4, 2023, SAP introduced the SAP Secure Login Service for SAP GUI, a cloud-centric solution that advances the concept of single sign-on. For comprehensive details, I direct your attention to the Release Blog post available here
By opting to retire the traditional AS Java platform, not only are cost efficiencies achieved but resource optimization is also realized. With a rhythmic alignment with Kerberos and X.509, coupled with seamless integration into cloud-driven identity frameworks, the opportune moment has arrived to engage with the SAP SSO cohort. The SAP Secure Login Service (SLS) builds upon the bedrock of SAP Single Sign-On, elevating the single sign-on experience to the cloud milieu. Embrace a lean cloud service seamlessly harmonizing with your corporate identity provider, as you embark on this transformative journey.
Source: SAP Secure Login Service for SAP GUI - Solution Overview
Multiple Factors Propel SAP's Move Towards New Solution for Enhanced Authentication
Let's begin by examining the key drivers behind SAP's introduction of this new solution. Currently, SAP SSO 3.0 remains in maintenance mode, with no new feature integrations from SAP. Notably, there are no plans for the release of Version 4.0.
Over time, certain scenarios have become obsolete, magnifying the demand to transition specific components (such as the Secure Login Server) to the cloud, a demand that has grown increasingly pronounced in recent years.
With the expansion of IT infrastructures reliant on cloud-native technologies and Azure AD, and in the absence of Active Directory (AD), there exists a pressing requirement for Multi-Factor Authentication (MFA) within the SAP GUI environment. The retirement of SAP AS Java has emerged as a pivotal factor thus far, underscoring the multifaceted motivations driving this shift. Indeed, it appears that a multitude of reasons converge to shape this transition.
Brief Overview of the SAP Secure Login Service for SAP GUI
The SAP Secure Login Service for SAP GUI is a multi-tenant SAP Business Technology Platform (BTP) cloud application designed to facilitate multifactor authentication (MFA) and single sign-on (SSO) when utilizing the SAP GUI interface.
Building upon the achievements of SAP Single Sign-On, the Secure Login Service (SLS) preserves its core functionalities while enhancing them to align with the demands of the cloud era. It seamlessly integrates with cloud-based identity providers, reinforcing authentication and single sign-on for business applications. By establishing connections with central authentication solutions like identity providers, this service streamlines access, enhances user efficiency, and reinforces data security through robust authentication methods.
It's all about keeping things simple and secure for your SAP GUI users. This new solution comes packed with a whole set of enhanced capabilities. One of the coolest things about this cloud-powered gem is the way it handles X.509 certificates. No more fussing around with on-premise servers or SAP NetWeaver Application Server Java. The cloud service takes care of all the certificate enrollment, leaving you with more time to binge-watch your favorite shows. So long, AS Java!
But wait, there's more! You can now flex your existing identity provider solution, like SAP Cloud Identity Services or other popular ones such as Microsoft Azure Active Directory and Okta. These authentication superheroes bring their mighty multi-factor authentication powers to the table, ensuring only the worthy can access your SAP GUI kingdom.
Highlights:
- Secure Login Client can authenticate SAP users based on the SAML standard (SAML & X.509).
- Supports SSO and MFA for SAP GUI without the need for a SAP NetWeaver AS Java instance (SLS).
- Enables previously missing functionalities such as SAP GUI SSO integration with SAML IdPs and MFA for SAP GUI without AS Java (SAP Secure Login Server).
- Provides an alternative to the Kerberos scenario (e.g. in pure Azure AD environments without KDC).
How it works in a nutshell:
- The Secure Login Client communicates with the new cloud service which can authenticate the user through IAS and/or an existing Corporate IdP (Azure|ADFS|Okta...).
- The "SLS in the Cloud" (user certificate service) issues a temporary SSO certificate.
- Technically, (after the SAML flow) this still involves an SNC connection with X.509 CBA (certificate-based authentication) to the AS ABAP or S/4HANA system.
Source: SAP Secure Login Service for SAP GUI - Solution Overview
Key Features:
- Configuration is based on your SAP Cloud Identity Services tenant or corporate Identity Provider (IdP). Various authentication factors such as passwords, Time-Based One-Time Password (TOTP) tokens, local X.509 certificates, and authentication devices like Windows Hello, macOS Touch ID, or FIDO can be configured.
- The Software-as-a-Service (SaaS) application offers a web-based user interface (UI) for administrative purposes. While the current Secure Login Service Web UI has limited settings, it's anticipated that additional features will be added in the future.
- Authentication takes place within an embedded web browser (part of the Secure Login Client in Windows) or the standard web browser (macOS version), contributing to an excellent user experience.
- Successful user authentication yields a short-lived user certificate, usable for Secure Network Communication (SNC), Secure Store and Forward (SSF), or Transport Layer Security (TLS).
- Users can authenticate to an AS ABAP (Advanced Business Application Programming) using X.509 certificates and Kerberos via SNC communication.
- Notably, the migration to the new service can be carried out seamlessly in parallel without disrupting the existing setup.
Source: SAP Secure Login Service for SAP GUI - Solution Overview
For more information, you can refer to the solution overview provided in this link: https://www.sap.com/documents/2023/05/50bf62e4-707e-0010-bca6-c68f7e60039b.html
To delve deeper into the topic of SAP Secure Login Service for SAP GUI, we recommend exploring the following resources for comprehensive information:
- Product overview presentation from SAP
- Documentation on SAP Help
Background
Before delving into the depths, let us initially provide a concise overview of why the current topic of Active Directory / Azure Active Directory holds relevance.
Embracing Change: Switching from Active Directory to Native Azure AD Environments
In the dynamic landscape of technological evolution, change stands as a pivotal determinant. Currently, a significant paradigm shift is underway, marked by the transition from conventional Active Directory (AD) environments to the native constructs of Azure Active Directory (AAD).
Especially prevalent in the initiatives of nascent enterprises commencing from their inception, a pronounced inclination towards a cloud-exclusive approach is often observed. In such scenarios, the conventional notion of a Domain, as commonly understood, may indeed lose its pertinence or operative status.
By harnessing the capabilities of cloud-based services and platforms, many organizations effectively obviate the need for traditional, on-premises domains, allowing them to fully leverage the advantages inherent to a cloud-native milieu. Facilitated by robust identity and access management solutions offered by cloud service providers, these enterprises can orchestrate secure and streamlined operations, thereby concentrating their efforts on fundamental business imperatives.
As these forward-looking entities wholeheartedly embrace the cloud as their principal infrastructure, they reap the rewards of its inherent flexibility, scalability, and cost-efficiency. Concurrently, the prevalence of cloud-native solutions and platforms renders the requirement for on-premises domains progressively obsolete, enabling enterprises to harness the potency of cloud services to fulfill both their IT and business prerequisites.
By committing to a cloud-exclusive methodology, these enterprises fully harness the capabilities proffered by cloud giants such as Microsoft Azure, AWS, or Google Cloud. They architect their infrastructure, applications, and services directly atop these platforms, capitalizing on the innate security, scalability, and availability features inherent in the cloud paradigm.
This transition toward an exclusive cloud-centric approach affords enterprises the luxury of concentrating on core business pursuits, unfettered by the complexities of managing and upkeeping conventional on-premises domains. Instead, they avail themselves of the cloud provider's infrastructure, empowering swift deployment and scalability of applications and services congruent with their burgeoning operations.
Furthermore, by embracing cloud-native offerings such as Azure Active Directory, enterprises can still uphold stringent access management and identity federation protocols without necessitating an on-premises domain. Azure AD extends an all-encompassing spectrum of identity and access management capabilities, encompassing Single Sign-On (SSO), Multi-Factor Authentication (MFA), and Conditional Access policies, seamlessly amalgamating with cloud-centric environments.
Ramifications on SAP Authentication Landscape
Thus, esteemed readers, let us pivot our attention to the trajectory of transition toward Azure's cloud-native approach and the ensuing implications on your SAP SSO landscape, particularly if you have traditionally relied on Kerberos authentication and have not yet traversed the realm of X.509 certificates for SAP GUI authentication.
The Migration to Azure AD
A growing cohort of global enterprises is unequivocally embracing the Azure and Intune ecosystem, bidding adieu to the conventional AD-domain construct. With Azure AD, clients emancipate themselves from the shackles of internal Active Directory systems, signifying the discontinuation of domain controllers and the prevailing of Kerberos Key Distribution Centers (KDCs). A farewell to erstwhile companions, indeed!
The Exodus of Kerberos
In the SAP domain, our endeavors have perennially revolved around realizing a seamless SSO experience via Kerberos authentication. However, in the nascent domain of Azure AD, this approach no longer retains its efficacy. The absence of domain controllers renders our cherished SAP GUI SSO solution, founded on SNC with Kerberos tokens, no longer as efficacious.
Introducing Azure Active Directory Domain Services
At this point, you might ask, "Can we use Kerberos in these new infrastructures?" The answer is found in Azure Active Directory Domain Services, which is like having two Domain Controllers offered as a service – quite a complex setup. When there's a noticeable lack of an LDAP infrastructure, some businesses might consider using these services to meet this need. I haven't had much experience with SAP SSO combined with these services so far. However, I'm keen to learn from anyone who has explored this option.
The Implications for SAP GUI
This technological shift undoubtedly impinges on SAP GUI. Ensuring encryption and SSO mandates continued safeguarding of all SAP proprietary DIAG and RFC communications through Secure Network Communications (SNC). Consequently, the necessity for the SAP SSO 3.0 solution (Secure Login Client) on client-side installations remains relatively unchanged within this novel framework.
HTTP-Driven SAP Applications and SAML 2.0
In recent times, SAML 2.0 has become the central standard in the SAP environment, especially for applications that operate over HTTP. Within the SAP ecosystem, which includes AS ABAP, AS Java, S/4HANA, and HANA DB, these systems act as service providers. They work together seamlessly with either the Azure Identity Provider (IDP) or the Identity Authentication Service (IAS), both of which are aligned with Azure AD. This forms a harmonious collaboration, like a symphony of interconnected champions.
When integrated with Azure AD, a world of opportunities emerges, with SAML 2.0 playing a pivotal role in single sign-on technology. This leads to the implementation of Conditional Access, Multi-Factor Authentication, and Intune policies for device recognition – a collection of security measures that can be likened to having your own team of security superheroes.
In the realm of SAP, whether within the On-Premises milieu or the SAP Cloud continuum (encompassing SaaS/BTP), the ascendancy of SAP Cloud Identity Services and SAP IAS remains unchallenged, serving as the paragons of Identity Providers. The integration with Azure AD not only remains a viable proposition but also avails itself of a multitude of advantages. For an in-depth elucidation, I direct your attention to this blog post.
SAP Cloud Identity Services
- Ideal for browser-based SAP access
- Enables SSO across cloud and on-premises apps
- Simplifies IAM for unified landscapes
- Supports SAML and OpenID Connect
SAP Single Sign-On 3.0
- Crucial for SAP GUI and on-premise systems
- Utilizes X.509 certificates or Kerberos (SNC)
- Ensures end-user SSO in various scenarios
SAP Secure Login Service for SAP GUI
- Official successor to SAP Single Sign-On 3.0 (post-2027)
- Enhances SAP GUI security
- Enables SAML-based authentication with Secure Login Client
- Integrates with existing SAML Identity Providers via SAP IAS
- Offers MFA support for SAP GUI, even without SAP NetWeaver AS Java (SLS)
- Replacement for Kerberos in pure Azure AD (Entra ID) environments
Big Picture: Authentication and SSO in a hybrid SAP system landscape
This graphic combines these three solutions to address your IAM and SSO needs, delivering a secure and user-friendly experience in your SAP landscape
Exploring the SAP Secure Login Service for SAP GUI: An In-Depth Review
In this chapter, you can expect the following:
- Information about the basic setup of the service (SAP BTP & IAS)
- Customization options for the X.509 DN of issued certificates
- Insights and some niceties about SNC User Mapping
- What's still missing and what could potentially be added in the future
Basic Setup of the Service (SAP BTP & IAS)
I was genuinely impressed by how straightforward the setup process is! While a few steps need to be followed, they are quite easy to manage. At a high level, without delving too deeply into the specifics, here are the 10 steps to success:
- License Assignment (Global Account Level): Assign the license to your Global Account (SAP SE).
- Define target BTP Subaccount: Establish a new BTP subaccount dedicated to the Secure Login Service (SLS).
- Trust Establishment: Establish trust between the SLS subaccount and your Identity Authentication Service (IAS) tenant.
- Configure Entitlement: Set up the entitlement and link the service to the SLS subaccount.
- Subscription: Subscribe to the Secure Login Service and generate a service instance.
- Group Setup in IAS: Create groups in IAS to control access to the Secure Login Service web UI.
- SSO Certificate Lifetime Configuration: Configure the lifespan of Single Sign-On (SSO) certificates in the SLS web UI.
- Common Name Attribute Setup: Establish the Common Name attribute for user certificates in IAS.
- Secure Login Client Deployment, Configuration and Policy Loading: Configure the Secure Login Client and provide the policy.
- Customization of SNC Names and CERTRULE: Customize the Secure Network Communication (SNC) names and certificate rules.
For detailed information, you can refer to the SAP Help guide for the SAP Secure Login Service for SAP GUI: https://help.sap.com/docs/SAP%20SECURE%20LOGIN%20SERVICE/c35917ca71e941c5a97a11d2c55dcacd/28d654c445...
In short:
- Licensing is tied to your Global Account and can be allocated to a pre-existing or new subaccount (Service Entitlement). This subaccount then hosts an instance of the SAP Secure Login Service for SAP GUI (Subscription). To establish this, the BTP subaccount must establish an OpenID Trust connection with one of your IAS tenants.
- Interestingly, it's worth noting that an IAS tenant from a different Global Account (with the same customer number) can also be leveraged, which is a beneficial feature.
- In conclusion, within IAS, you'll discover two applications: the Subaccount Trust XSUAA_<subaccount> (associated with your BTP subaccount trust) and the <secure-login-service>_<region> (your instance of the User Certificate Service). For the latter application, you can set up a Conditional Authentication Rule that allows optional redirection to your Corporate Identity Provider, which, in our case, was Azure AD.
- Accessing the web UI necessitates membership in two groups: SecureLoginServiceAdministrator and SecureLoginServiceViewer in IAS. Importantly, the SAP Secure Login Service for SAP GUI doesn't have its own set of BTP cockpit roles or role collections; instead, service access authorizations are administered through the trusted IAS tenant.
- From there, you can obtain the Client Policy Groups Host URL (found as enrollURL0), a crucial element for configuring the Secure Login Client Policy. This configuration ultimately enables the acquisition of certificates from the cloud certificate service operating within your BTP subaccount.
- By the way, the Client Setup process has remained unchanged. The Secure Login Client (SLC) can still be deployed manually or through automated means, and configuration can be automated using Registry Keys (Intune, GPO etc.).
And with that, the essentials have been covered.
Customization Options for X.509 DN in Issued Certificates
Regarding X.509 DN, well, it's just how it is.
While the common names (CN) of user certificates are unique and dynamic, the static suffix is generated by the Secure Login Service and represents the identifier for the IAS tenant and SLS region. The CN part of the certificate's Distinguished Name is configured within the IAS application, following this procedure: https://help.sap.com/docs/SAP%20SECURE%20LOGIN%20SERVICE/c35917ca71e941c5a97a11d2c55dcacd/81fe0a1211...
In our scenario, we aimed to include the email address from IAS as the CN in the certificate. This email attribute is sourced from the IAS user store (IdDS), which is synchronized with users from our Azure AD tenant. However, you could also retrieve this attribute directly from your chosen Corporate Identity Provider (IdP), especially if you don't have profiles in IAS (no Identity Federation).
The certificate's structure will be formed using the following X.509 DN - Example:
CN=<E-Mail>, L=<ias-tenant>.accounts.ondemand.com, OU=<SLS-region-id>, OU=SAP BTP Clients, O=SAP SE, C=DE
This customization allows for tailoring the certificate to incorporate specific attributes from your chosen identity source, enhancing the certificate's relevance and usefulness within your system.
Source: SAP Secure Login Service for SAP GUI - Solution Overview
Certificate Chain of the SAP-Managed PKI
By the way, the certificate chain of the issued temporary SSO certificates can be traced back to the SAP Cloud Root CA, which has a validity of 20 years. This is the well-known certification authority that also issues SAP Passports (S-User Certificates), among other things.
Beneath this, there is the SAP BTP Client CA with a validity of 10 years, followed by the actual Issuing CA, SAP PKI Certificate Service Client CA, which has a validity of 2 months and is regularly renewed by SAP. Ultimately, in the SAP backend, the trust relationship to the root certificate must be established within the necessary PSE containers.
Here's the complete CA chain:
SAP Cloud Root CA
|- SAP BTP Client CA
|- SAP PKI Certificate Service Client CA
Aspects and Some Nice Features of SNC User Mapping
When implementing the new solution, adjustments to SNC names become necessary. There are various approaches to mass-set SNC names. While using the RSUSR300 report might pose some challenges, a Central User Administration (CUA) or Identity Management (IDM) systems are equally helpful.
Custom reports, as well as tools like our XAMS can also be used. With those you can easily create an Excel sheet with a generic formula, upload the sheet, and voilà, you're good to go.
By the way, it's worth noting that you can shorten parts of the long Distinguished Name (DN) using SAP CCL (CommonCryptoLib) ccl/* profile parameters. However, this requires configuration in the default profile on a per-system basis. Further information can be found here:
https://help.sap.com/docs/SAP_SINGLE_SIGN-ON/df185fd53bb645b1bd99284ee4e4a750/ca4af653ac444b54ba7fbb... and in SAP Note 2338952: https://me.sap.com/notes/2338952/E
Here's an example of how the configuration might look
ccl/snc/namealias/value_1 = L=<iastenant>.accounts.ondemand.com
ccl/snc/namealias/replacement_1 = L=My-IAS
ccl/snc/namealias/value_2 = OU=<region>-secure-login-service
ccl/snc/namealias/replacement_2 = OU=SLS
ccl/snc/namealias/value_3 = OU=SAP BTP Clients
ccl/snc/namealias/replacement_3 = OU=BTP
Original SNC Name:
p:CN=<E-Mail>, L=<iastenant>.accounts.ondemand.com, OU=<region>-secure-login-service, OU=SAP BTP Clients, O=SAP SE, C=DE
After applying the configurations, the modified SNC name would appear as follows:
p:CN=<E-Mail>, L=My-IAS, OU=SLS, OU=BTP, O=SAP SE, C=DE
Additionally, in the transaction CERTRULE, you can create a new rule quite easily. We simply mapped the CN part to the SU01 field "E-Mail" and filtered out all other DN elements like L, OU, O, and C.
What's Still Missing and What Could Come Next
Please bear in mind that I am not part of SAP's Product Management team 😇, and the following points are based on my personal opinion.
Certain aspects from the SAP SSO 3.0 suite are not currently covered by the new solution, and there hasn't been much change in this regard. Nevertheless, we would like to address some current limitations of the service and provide insights into its potential future developments.
Here are some points we'd like to share with you:
Customization of X.509 DN is currently not possible: Currently, adjusting the X.509 DN is not feasible, and it follows a fixed structure. It would be fantastic if the lengthy part after the CN could be customized. Unfortunately, the X.509 DN is even so lengthy that the RSUSR300 report (SNC1) struggles to handle it due to a field length restriction.
UPDATE: As of November 6, 2023, SAP Note 3396732 (SNC1/RSUSR300) has been released, providing support for extended prefix and suffix values. This update addresses the previous limitation, now allowing a field length of up to 200 characters.
According to SAP, the X.509 DN will become configurable once the custom cloud CA (Certificate Authority) support goes live. Integrating a customer-specific cloud CA is on the roadmap. However, it's unlikely that a similar option to the old SLS, using Remote CAs through NDES & Cloud Connector, will be available.
Profiles/Profile Groups Not Currently Supported: Presently, using profiles or profile groups to enforce true Multi-Factor Authentication (MFA) requirements for specific SAP systems isn't feasible. In the previous SLS version, certificates could be removed after a timeout, or there was the option to automatically log off from the profile when the last SNC session was closed. With the new solution, this isn't currently achievable for individual GssTargetNames.
Different profiles can only be represented through separate subscriptions, which is a bit of a drawback. Additionally, some settings familiar from SLS 3.0 are not yet available in the new cloud solution. SAP might observe customer demand before implementing these.
Certificate Lifecycle Management (CLM) Similar to the old SAP SLS 3.0: The management of certificate lifecycles (CLM), akin to the old SLS, is not currently planned. SAP hasn't provided a timeline, but this will be explored more closely once the custom cloud CA support is in place. Currently, customers would need to license both solutions – the minimum bundle for SAP SSO 3.0, and the new solution.
As the solution evolves and more feedback is gathered from users, SAP might address these limitations and introduce new features. The complexities surrounding certificate management and authentication are areas of ongoing development. Let's see how the solution will evolve over time.
We conclude this blog with a collection of FAQs.
Compilation of frequently asked questions
Q: What happens if the cloud service is unavailable due to IaaS provider network issues (SAP/AWS/Microsoft Azure/Google CP)?
A: The certificate service operates on SAP BTP, following platform availability commitments. While cloud service is needed for certificate provisioning, typical validity spans a workday. Users access the service once daily, enabling independent ABAP system use. In case of service unavailability, alternative on-premises solutions like certificates, smart cards, or Kerberos are recommended.
Q: Can users of SAP SSO 3.0 and SAP Secure Login Server transition to the cloud? Are there commercial advantages or parallel product usage?
A: SAP SSO 3.0 and SLS differ in licensing and features. SLS benefits include better cloud identity provider integration and reduced total cost of ownership by eliminating AS Java operation. Technical intricacies of SLS 3.0 might not fully transfer. Commercial transition details can be discussed with your SAP Account Executive.
Q: Can CPEA Global Accounts subscribe to SAP Secure Login Service for SAP GUI?
A: Currently, CPEA is not supported. Minimal subscriptions are available through SAP contacts to facilitate starting. No trial version is offered by SAP SE at present.
Q: Is SAP Secure Login Service the official successor to SAP Single Sign-On 3.0 after 2027 end of maintenance?
A: Yes, SAP Secure Login Service for SAP GUI will replace SAP Single Sign-On 3.0.
Q: What benefits does SAP Secure Login Service offer over SAP Single Sign-On 3.0 for complex on-premise SAP landscapes using Kerberos?
A: Both products offer Kerberos-based single sign-on with no difference. Transition isn't necessary unless supporting multiple ADs/Forests or consolidating authentication via central Azure AD tenant. Migration enhances flexibility and future-proofing.
Q: Does SAP Secure Login Service for SAP GUI support SAP Fiori or SAP GUI HTML?
A: Http-based apps can use SAML 2.0 or X.509 certificates, possibly without this solution. SPNEGO is feasible if SAP Secure Login Service for SAP GUI functions solely as a Kerberos solution.
Q: Is SAP Cloud Identity Authentication Service (IAS) essential for SAP Secure Login Service for SAP GUI?
A: Identity Authentication Service is integral, but can proxy Azure AD. This way, users interact only with Azure AD interfaces.
[Last Update 2024.03.01]
Hello fellow SAP security enthusiasts!
I wanted to share some exciting news with you. I've been busy creating a couple of LinkedIn blogs that delve into the fascinating world of the SAP Secure Login Service for SAP GUI. As I was exploring this topic, I thought, why not bring all this valuable knowledge together into one comprehensive blog post?
I hope you enjoy reading it as much as I enjoyed writing it!
TOC
Introduction
Multiple Factors Propel SAP's Move Towards New Solution for Enhanced Authentication
Brief Overview of the SAP Secure Login Service for SAP GUI
Background
Embracing Change: Switching from Active Directory to Native Azure AD Environments
Ramifications on SAP Authentication Landscape
The Migration to Azure AD
The Exodus of Kerberos
Introducing Azure Active Directory Domain Services
The Implications for SAP GUI
HTTP-Driven SAP Applications and SAML 2.0
Exploring the SAP Secure Login Service for SAP GUI: An In-Depth Review
Basic Setup of the Service (SAP BTP & IAS)
Customization Options for X.509 DN in Issued Certificates
Certificate Chain of the SAP-Managed PKI
Aspects and Some Nice Features of SNC User Mapping
What's Still Missing and What Could Come Nex
Compilation of frequently asked questions
Introduction
The highly anticipated SAP Secure Login Service for SAP GUI has emerged as a testament to innovation, merging the stalwart functionality of the esteemed SAP Single Sign-On with the expansive capabilities of cloud computing.
On May 4, 2023, SAP introduced the SAP Secure Login Service for SAP GUI, a cloud-centric solution that advances the concept of single sign-on. For comprehensive details, I direct your attention to the Release Blog post available here
By opting to retire the traditional AS Java platform, not only are cost efficiencies achieved but resource optimization is also realized. With a rhythmic alignment with Kerberos and X.509, coupled with seamless integration into cloud-driven identity frameworks, the opportune moment has arrived to engage with the SAP SSO cohort. The SAP Secure Login Service (SLS) builds upon the bedrock of SAP Single Sign-On, elevating the single sign-on experience to the cloud milieu. Embrace a lean cloud service seamlessly harmonizing with your corporate identity provider, as you embark on this transformative journey.
Source: SAP Secure Login Service for SAP GUI - Solution Overview
Multiple Factors Propel SAP's Move Towards New Solution for Enhanced Authentication
Let's begin by examining the key drivers behind SAP's introduction of this new solution. Currently, SAP SSO 3.0 remains in maintenance mode, with no new feature integrations from SAP. Notably, there are no plans for the release of Version 4.0.
Over time, certain scenarios have become obsolete, magnifying the demand to transition specific components (such as the Secure Login Server) to the cloud, a demand that has grown increasingly pronounced in recent years.
With the expansion of IT infrastructures reliant on cloud-native technologies and Azure AD, and in the absence of Active Directory (AD), there exists a pressing requirement for Multi-Factor Authentication (MFA) within the SAP GUI environment. The retirement of SAP AS Java has emerged as a pivotal factor thus far, underscoring the multifaceted motivations driving this shift. Indeed, it appears that a multitude of reasons converge to shape this transition.
Brief Overview of the SAP Secure Login Service for SAP GUI
The SAP Secure Login Service for SAP GUI is a multi-tenant SAP Business Technology Platform (BTP) cloud application designed to facilitate multifactor authentication (MFA) and single sign-on (SSO) when utilizing the SAP GUI interface.
Building upon the achievements of SAP Single Sign-On, the Secure Login Service (SLS) preserves its core functionalities while enhancing them to align with the demands of the cloud era. It seamlessly integrates with cloud-based identity providers, reinforcing authentication and single sign-on for business applications. By establishing connections with central authentication solutions like identity providers, this service streamlines access, enhances user efficiency, and reinforces data security through robust authentication methods.
It's all about keeping things simple and secure for your SAP GUI users. This new solution comes packed with a whole set of enhanced capabilities. One of the coolest things about this cloud-powered gem is the way it handles X.509 certificates. No more fussing around with on-premise servers or SAP NetWeaver Application Server Java. The cloud service takes care of all the certificate enrollment, leaving you with more time to binge-watch your favorite shows. So long, AS Java!
But wait, there's more! You can now flex your existing identity provider solution, like SAP Cloud Identity Services or other popular ones such as Microsoft Azure Active Directory and Okta. These authentication superheroes bring their mighty multi-factor authentication powers to the table, ensuring only the worthy can access your SAP GUI kingdom.
Highlights:
- Secure Login Client can authenticate SAP users based on the SAML standard (SAML & X.509).
- Supports SSO and MFA for SAP GUI without the need for a SAP NetWeaver AS Java instance (SLS).
- Enables previously missing functionalities such as SAP GUI SSO integration with SAML IdPs and MFA for SAP GUI without AS Java (SAP Secure Login Server).
- Provides an alternative to the Kerberos scenario (e.g. in pure Azure AD environments without KDC).
How it works in a nutshell:
- The Secure Login Client communicates with the new cloud service which can authenticate the user through IAS and/or an existing Corporate IdP (Azure|ADFS|Okta...).
- The "SLS in the Cloud" (user certificate service) issues a temporary SSO certificate.
- Technically, (after the SAML flow) this still involves an SNC connection with X.509 CBA (certificate-based authentication) to the AS ABAP or S/4HANA system.
Source: SAP Secure Login Service for SAP GUI - Solution Overview
Key Features:
- Configuration is based on your SAP Cloud Identity Services tenant or corporate Identity Provider (IdP). Various authentication factors such as passwords, Time-Based One-Time Password (TOTP) tokens, local X.509 certificates, and authentication devices like Windows Hello, macOS Touch ID, or FIDO can be configured.
- The Software-as-a-Service (SaaS) application offers a web-based user interface (UI) for administrative purposes. While the current Secure Login Service Web UI has limited settings, it's anticipated that additional features will be added in the future.
- Authentication takes place within an embedded web browser (part of the Secure Login Client in Windows) or the standard web browser (macOS version), contributing to an excellent user experience.
- Successful user authentication yields a short-lived user certificate, usable for Secure Network Communication (SNC), Secure Store and Forward (SSF), or Transport Layer Security (TLS).
- Users can authenticate to an AS ABAP (Advanced Business Application Programming) using X.509 certificates and Kerberos via SNC communication.
- Notably, the migration to the new service can be carried out seamlessly in parallel without disrupting the existing setup.
Source: SAP Secure Login Service for SAP GUI - Solution Overview
For more information, you can refer to the solution overview provided in this link: https://www.sap.com/documents/2023/05/50bf62e4-707e-0010-bca6-c68f7e60039b.html
To delve deeper into the topic of SAP Secure Login Service for SAP GUI, we recommend exploring the following resources for comprehensive information:
- Product overview presentation from SAP
- Documentation on SAP Help
Background
Before delving into the depths, let us initially provide a concise overview of why the current topic of Active Directory / Azure Active Directory holds relevance.
Embracing Change: Switching from Active Directory to Native Azure AD Environments
In the dynamic landscape of technological evolution, change stands as a pivotal determinant. Currently, a significant paradigm shift is underway, marked by the transition from conventional Active Directory (AD) environments to the native constructs of Azure Active Directory (AAD).
Especially prevalent in the initiatives of nascent enterprises commencing from their inception, a pronounced inclination towards a cloud-exclusive approach is often observed. In such scenarios, the conventional notion of a Domain, as commonly understood, may indeed lose its pertinence or operative status.
By harnessing the capabilities of cloud-based services and platforms, many organizations effectively obviate the need for traditional, on-premises domains, allowing them to fully leverage the advantages inherent to a cloud-native milieu. Facilitated by robust identity and access management solutions offered by cloud service providers, these enterprises can orchestrate secure and streamlined operations, thereby concentrating their efforts on fundamental business imperatives.
As these forward-looking entities wholeheartedly embrace the cloud as their principal infrastructure, they reap the rewards of its inherent flexibility, scalability, and cost-efficiency. Concurrently, the prevalence of cloud-native solutions and platforms renders the requirement for on-premises domains progressively obsolete, enabling enterprises to harness the potency of cloud services to fulfill both their IT and business prerequisites.
By committing to a cloud-exclusive methodology, these enterprises fully harness the capabilities proffered by cloud giants such as Microsoft Azure, AWS, or Google Cloud. They architect their infrastructure, applications, and services directly atop these platforms, capitalizing on the innate security, scalability, and availability features inherent in the cloud paradigm.
This transition toward an exclusive cloud-centric approach affords enterprises the luxury of concentrating on core business pursuits, unfettered by the complexities of managing and upkeeping conventional on-premises domains. Instead, they avail themselves of the cloud provider's infrastructure, empowering swift deployment and scalability of applications and services congruent with their burgeoning operations.
Furthermore, by embracing cloud-native offerings such as Azure Active Directory, enterprises can still uphold stringent access management and identity federation protocols without necessitating an on-premises domain. Azure AD extends an all-encompassing spectrum of identity and access management capabilities, encompassing Single Sign-On (SSO), Multi-Factor Authentication (MFA), and Conditional Access policies, seamlessly amalgamating with cloud-centric environments.
Ramifications on SAP Authentication Landscape
Thus, esteemed readers, let us pivot our attention to the trajectory of transition toward Azure's cloud-native approach and the ensuing implications on your SAP SSO landscape, particularly if you have traditionally relied on Kerberos authentication and have not yet traversed the realm of X.509 certificates for SAP GUI authentication.
The Migration to Azure AD
A growing cohort of global enterprises is unequivocally embracing the Azure and Intune ecosystem, bidding adieu to the conventional AD-domain construct. With Azure AD, clients emancipate themselves from the shackles of internal Active Directory systems, signifying the discontinuation of domain controllers and the prevailing of Kerberos Key Distribution Centers (KDCs). A farewell to erstwhile companions, indeed!
The Exodus of Kerberos
In the SAP domain, our endeavors have perennially revolved around realizing a seamless SSO experience via Kerberos authentication. However, in the nascent domain of Azure AD, this approach no longer retains its efficacy. The absence of domain controllers renders our cherished SAP GUI SSO solution, founded on SNC with Kerberos tokens, no longer as efficacious.
Introducing Azure Active Directory Domain Services
At this point, you might ask, "Can we use Kerberos in these new infrastructures?" The answer is found in Azure Active Directory Domain Services, which is like having two Domain Controllers offered as a service – quite a complex setup. When there's a noticeable lack of an LDAP infrastructure, some businesses might consider using these services to meet this need. I haven't had much experience with SAP SSO combined with these services so far. However, I'm keen to learn from anyone who has explored this option.
The Implications for SAP GUI
This technological shift undoubtedly impinges on SAP GUI. Ensuring encryption and SSO mandates continued safeguarding of all SAP proprietary DIAG and RFC communications through Secure Network Communications (SNC). Consequently, the necessity for the SAP SSO 3.0 solution (Secure Login Client) on client-side installations remains relatively unchanged within this novel framework.
HTTP-Driven SAP Applications and SAML 2.0
In recent times, SAML 2.0 has become the central standard in the SAP environment, especially for applications that operate over HTTP. Within the SAP ecosystem, which includes AS ABAP, AS Java, S/4HANA, and HANA DB, these systems act as service providers. They work together seamlessly with either the Azure Identity Provider (IDP) or the Identity Authentication Service (IAS), both of which are aligned with Azure AD. This forms a harmonious collaboration, like a symphony of interconnected champions.
When integrated with Azure AD, a world of opportunities emerges, with SAML 2.0 playing a pivotal role in single sign-on technology. This leads to the implementation of Conditional Access, Multi-Factor Authentication, and Intune policies for device recognition – a collection of security measures that can be likened to having your own team of security superheroes.
In the realm of SAP, whether within the On-Premises milieu or the SAP Cloud continuum (encompassing SaaS/BTP), the ascendancy of SAP Cloud Identity Services and SAP IAS remains unchallenged, serving as the paragons of Identity Providers. The integration with Azure AD not only remains a viable proposition but also avails itself of a multitude of advantages. For an in-depth elucidation, I direct your attention to this blog post.
SAP Cloud Identity Services
- Ideal for browser-based SAP access
- Enables SSO across cloud and on-premises apps
- Simplifies IAM for unified landscapes
- Supports SAML and OpenID Connect
SAP Single Sign-On 3.0
- Crucial for SAP GUI and on-premise systems
- Utilizes X.509 certificates or Kerberos (SNC)
- Ensures end-user SSO in various scenarios
SAP Secure Login Service for SAP GUI
- Official successor to SAP Single Sign-On 3.0 (post-2027)
- Enhances SAP GUI security
- Enables SAML-based authentication with Secure Login Client
- Integrates with existing SAML Identity Providers via SAP IAS
- Offers MFA support for SAP GUI, even without SAP NetWeaver AS Java (SLS)
- Replacement for Kerberos in pure Azure AD (Entra ID) environments
Big Picture: Authentication and SSO in a hybrid SAP system landscape
This graphic combines these three solutions to address your IAM and SSO needs, delivering a secure and user-friendly experience in your SAP landscape
Exploring the SAP Secure Login Service for SAP GUI: An In-Depth Review
In this chapter, you can expect the following:
- Information about the basic setup of the service (SAP BTP & IAS)
- Customization options for the X.509 DN of issued certificates
- Insights and some niceties about SNC User Mapping
- What's still missing and what could potentially be added in the future
Basic Setup of the Service (SAP BTP & IAS)
I was genuinely impressed by how straightforward the setup process is! While a few steps need to be followed, they are quite easy to manage. At a high level, without delving too deeply into the specifics, here are the 10 steps to success:
- License Assignment (Global Account Level): Assign the license to your Global Account (SAP SE).
- Define target BTP Subaccount: Establish a new BTP subaccount dedicated to the Secure Login Service (SLS).
- Trust Establishment: Establish trust between the SLS subaccount and your Identity Authentication Service (IAS) tenant.
- Configure Entitlement: Set up the entitlement and link the service to the SLS subaccount.
- Subscription: Subscribe to the Secure Login Service and generate a service instance.
- Group Setup in IAS: Create groups in IAS to control access to the Secure Login Service web UI.
- SSO Certificate Lifetime Configuration: Configure the lifespan of Single Sign-On (SSO) certificates in the SLS web UI.
- Common Name Attribute Setup: Establish the Common Name attribute for user certificates in IAS.
- Secure Login Client Deployment, Configuration and Policy Loading: Configure the Secure Login Client and provide the policy.
- Customization of SNC Names and CERTRULE: Customize the Secure Network Communication (SNC) names and certificate rules.
For detailed information, you can refer to the SAP Help guide for the SAP Secure Login Service for SAP GUI: https://help.sap.com/docs/SAP%20SECURE%20LOGIN%20SERVICE/c35917ca71e941c5a97a11d2c55dcacd/28d654c445...
In short:
- Licensing is tied to your Global Account and can be allocated to a pre-existing or new subaccount (Service Entitlement). This subaccount then hosts an instance of the SAP Secure Login Service for SAP GUI (Subscription). To establish this, the BTP subaccount must establish an OpenID Trust connection with one of your IAS tenants.
- Interestingly, it's worth noting that an IAS tenant from a different Global Account (with the same customer number) can also be leveraged, which is a beneficial feature.
- In conclusion, within IAS, you'll discover two applications: the Subaccount Trust XSUAA_<subaccount> (associated with your BTP subaccount trust) and the <secure-login-service>_<region> (your instance of the User Certificate Service). For the latter application, you can set up a Conditional Authentication Rule that allows optional redirection to your Corporate Identity Provider, which, in our case, was Azure AD.
- Accessing the web UI necessitates membership in two groups: SecureLoginServiceAdministrator and SecureLoginServiceViewer in IAS. Importantly, the SAP Secure Login Service for SAP GUI doesn't have its own set of BTP cockpit roles or role collections; instead, service access authorizations are administered through the trusted IAS tenant.
- From there, you can obtain the Client Policy Groups Host URL (found as enrollURL0), a crucial element for configuring the Secure Login Client Policy. This configuration ultimately enables the acquisition of certificates from the cloud certificate service operating within your BTP subaccount.
- By the way, the Client Setup process has remained unchanged. The Secure Login Client (SLC) can still be deployed manually or through automated means, and configuration can be automated using Registry Keys (Intune, GPO etc.).
And with that, the essentials have been covered.
Customization Options for X.509 DN in Issued Certificates
Regarding X.509 DN, well, it's just how it is.
While the common names (CN) of user certificates are unique and dynamic, the static suffix is generated by the Secure Login Service and represents the identifier for the IAS tenant and SLS region. The CN part of the certificate's Distinguished Name is configured within the IAS application, following this procedure: https://help.sap.com/docs/SAP%20SECURE%20LOGIN%20SERVICE/c35917ca71e941c5a97a11d2c55dcacd/81fe0a1211...
In our scenario, we aimed to include the email address from IAS as the CN in the certificate. This email attribute is sourced from the IAS user store (IdDS), which is synchronized with users from our Azure AD tenant. However, you could also retrieve this attribute directly from your chosen Corporate Identity Provider (IdP), especially if you don't have profiles in IAS (no Identity Federation).
The certificate's structure will be formed using the following X.509 DN - Example:
CN=<E-Mail>, L=<ias-tenant>.accounts.ondemand.com, OU=<SLS-region-id>, OU=SAP BTP Clients, O=SAP SE, C=DE
This customization allows for tailoring the certificate to incorporate specific attributes from your chosen identity source, enhancing the certificate's relevance and usefulness within your system.
Source: SAP Secure Login Service for SAP GUI - Solution Overview
Certificate Chain of the SAP-Managed PKI
By the way, the certificate chain of the issued temporary SSO certificates can be traced back to the SAP Cloud Root CA, which has a validity of 20 years. This is the well-known certification authority that also issues SAP Passports (S-User Certificates), among other things.
Beneath this, there is the SAP BTP Client CA with a validity of 10 years, followed by the actual Issuing CA, SAP PKI Certificate Service Client CA, which has a validity of 2 months and is regularly renewed by SAP. Ultimately, in the SAP backend, the trust relationship to the root certificate must be established within the necessary PSE containers.
Here's the complete CA chain:
SAP Cloud Root CA
|- SAP BTP Client CA
|- SAP PKI Certificate Service Client CA
Aspects and Some Nice Features of SNC User Mapping
When implementing the new solution, adjustments to SNC names become necessary. There are various approaches to mass-set SNC names. While using the RSUSR300 report might pose some challenges, a Central User Administration (CUA) or Identity Management (IDM) systems are equally helpful.
Custom reports, as well as tools like our XAMS can also be used. With those you can easily create an Excel sheet with a generic formula, upload the sheet, and voilà, you're good to go.
By the way, it's worth noting that you can shorten parts of the long Distinguished Name (DN) using SAP CCL (CommonCryptoLib) ccl/* profile parameters. However, this requires configuration in the default profile on a per-system basis. Further information can be found here:
https://help.sap.com/docs/SAP_SINGLE_SIGN-ON/df185fd53bb645b1bd99284ee4e4a750/ca4af653ac444b54ba7fbb... and in SAP Note 2338952: https://me.sap.com/notes/2338952/E
Here's an example of how the configuration might look
ccl/snc/namealias/value_1 = L=<iastenant>.accounts.ondemand.com
ccl/snc/namealias/replacement_1 = L=My-IAS
ccl/snc/namealias/value_2 = OU=<region>-secure-login-service
ccl/snc/namealias/replacement_2 = OU=SLS
ccl/snc/namealias/value_3 = OU=SAP BTP Clients
ccl/snc/namealias/replacement_3 = OU=BTP
Original SNC Name:
p:CN=<E-Mail>, L=<iastenant>.accounts.ondemand.com, OU=<region>-secure-login-service, OU=SAP BTP Clients, O=SAP SE, C=DE
After applying the configurations, the modified SNC name would appear as follows:
p:CN=<E-Mail>, L=My-IAS, OU=SLS, OU=BTP, O=SAP SE, C=DE
Additionally, in the transaction CERTRULE, you can create a new rule quite easily. We simply mapped the CN part to the SU01 field "E-Mail" and filtered out all other DN elements like L, OU, O, and C.
What's Still Missing and What Could Come Next
Please bear in mind that I am not part of SAP's Product Management team 😇, and the following points are based on my personal opinion.
Certain aspects from the SAP SSO 3.0 suite are not currently covered by the new solution, and there hasn't been much change in this regard. Nevertheless, we would like to address some current limitations of the service and provide insights into its potential future developments.
Here are some points we'd like to share with you:
Customization of X.509 DN is currently not possible: Currently, adjusting the X.509 DN is not feasible, and it follows a fixed structure. It would be fantastic if the lengthy part after the CN could be customized. Unfortunately, the X.509 DN is even so lengthy that the RSUSR300 report (SNC1) struggles to handle it due to a field length restriction.
UPDATE: As of November 6, 2023, SAP Note 3396732 (SNC1/RSUSR300) has been released, providing support for extended prefix and suffix values. This update addresses the previous limitation, now allowing a field length of up to 200 characters.
According to SAP, the X.509 DN will become configurable once the custom cloud CA (Certificate Authority) support goes live. Integrating a customer-specific cloud CA is on the roadmap. However, it's unlikely that a similar option to the old SLS, using Remote CAs through NDES & Cloud Connector, will be available.
Profiles/Profile Groups Not Currently Supported: Presently, using profiles or profile groups to enforce true Multi-Factor Authentication (MFA) requirements for specific SAP systems isn't feasible. In the previous SLS version, certificates could be removed after a timeout, or there was the option to automatically log off from the profile when the last SNC session was closed. With the new solution, this isn't currently achievable for individual GssTargetNames.
Different profiles can only be represented through separate subscriptions, which is a bit of a drawback. Additionally, some settings familiar from SLS 3.0 are not yet available in the new cloud solution. SAP might observe customer demand before implementing these.
Certificate Lifecycle Management (CLM) Similar to the old SAP SLS 3.0: The management of certificate lifecycles (CLM), akin to the old SLS, is not currently planned. SAP hasn't provided a timeline, but this will be explored more closely once the custom cloud CA support is in place. Currently, customers would need to license both solutions – the minimum bundle for SAP SSO 3.0, and the new solution.
As the solution evolves and more feedback is gathered from users, SAP might address these limitations and introduce new features. The complexities surrounding certificate management and authentication are areas of ongoing development. Let's see how the solution will evolve over time.
We conclude this blog with a collection of FAQs.
Compilation of frequently asked questions
Q: What happens if the cloud service is unavailable due to IaaS provider network issues (SAP/AWS/Microsoft Azure/Google CP)?
A: The certificate service operates on SAP BTP, following platform availability commitments. While cloud service is needed for certificate provisioning, typical validity spans a workday. Users access the service once daily, enabling independent ABAP system use. In case of service unavailability, alternative on-premises solutions like certificates, smart cards, or Kerberos are recommended.
Q: Can users of SAP SSO 3.0 and SAP Secure Login Server transition to the cloud? Are there commercial advantages or parallel product usage?
A: SAP SSO 3.0 and SLS differ in licensing and features. SLS benefits include better cloud identity provider integration and reduced total cost of ownership by eliminating AS Java operation. Technical intricacies of SLS 3.0 might not fully transfer. Commercial transition details can be discussed with your SAP Account Executive.
Q: Can CPEA Global Accounts subscribe to SAP Secure Login Service for SAP GUI?
A: Currently, CPEA is not supported. Minimal subscriptions are available through SAP contacts to facilitate starting. No trial version is offered by SAP SE at present.
Q: Is SAP Secure Login Service the official successor to SAP Single Sign-On 3.0 after 2027 end of maintenance?
A: Yes, SAP Secure Login Service for SAP GUI will replace SAP Single Sign-On 3.0.
Q: What benefits does SAP Secure Login Service offer over SAP Single Sign-On 3.0 for complex on-premise SAP landscapes using Kerberos?
A: Both products offer Kerberos-based single sign-on with no difference. Transition isn't necessary unless supporting multiple ADs/Forests or consolidating authentication via central Azure AD tenant. Migration enhances flexibility and future-proofing.
Q: Does SAP Secure Login Service for SAP GUI support SAP Fiori or SAP GUI HTML?
A: Http-based apps can use SAML 2.0 or X.509 certificates, possibly without this solution. SPNEGO is feasible if SAP Secure Login Service for SAP GUI functions solely as a Kerberos solution.
Q: Is SAP Cloud Identity Authentication Service (IAS) essential for SAP Secure Login Service for SAP GUI?
A: Identity Authentication Service is integral, but can proxy Azure AD. This way, users interact only with Azure AD interfaces.
Q:Is there a direct correlation between the number of "SAP Secure Login Service for SAP GUI" instances and "SAP Cloud Authentication Service" instances? Specifically, if a customer has three IAS instances due to a one-to-one relationship with SuccessFactors instances (Production, Non-Production 1, and Non-Production 2), each linked to corresponding SuccessFactors and S4HANA environments, is it necessary to have three separate SAP Secure Login Service instances for SSO in S4HANA environments (Prod, Test, Development)? Also, does the pricing for SAP Secure Login Service only apply to production usage?
A: SAP Secure Login Service doesn't have its own user store and always relies on the identity provider, such as IAS, for authentication. To enable SSO for a specific S/4HANA system, an SAP Secure Login Service instance must be integrated with an IAS tenant containing the relevant user accounts. If the productive IAS tenant lacks certain user accounts, additional SAP Secure Login Service instances are required for other IAS tenants. Pricing is determined by the number of users or employees, not by the number of SAP Secure Login Service instances.
Q: Can Azure Idp be used without a BTP tenant for authentication?
A: Secure Login Client relies on BTP's SAP Secure Login Service for certificate provisioning and Identity Authentication Service for authentication. Azure AD integration is enabled through proxy configuration in Identity Authentication Service and Azure AD.
Q: Does "SAP Secure Login Service for SAP GUI" include Certificate Lifecycle Management (CLM)?
A: Current version lacks CLM. SAP considers cloud-based alternatives to on-premise Java stack for future CLM inclusion, with details and timelines pending.
Q: How can we perform tasks such as creating root certificates, intermediates, signing certificates with CSR, and installing them into ABAP/JAVA systems using the new SAP Secure Login Service for SAP GUI?
A: Currently, the new service primarily deals with client certificates for SSO using an SAP-managed CA. Support for customer-managed CAs in the cloud is on the roadmap, but not yet available. Certificate Lifecycle Management is under consideration, but the scope and roadmap haven't been finalized. Thus, the functionality of the on-premise server for creating root certificates, intermediates, signing certificates with CSR etc. is not available in the cloud service at this time.
Q: Does the Secure Login Service for SAP GUI running on SAP Business Technology Platform - will only function within the client's network, as it may not be able to communicate with the corporate on-premises IDP (Identity Provider) from outside the network due to potential connectivity restrictions?
A: In this case, SAP utilize the IAS identity provider proxy mechanism, detailed at https://help.sap.com/docs/identity-authentication/identity-authentication/corporate-identity-provide.... This setup eliminates the need for a network connection between the two identity providers, as all communication occurs through the end user's browser. The only requirement is that both the identity authentication service and your corporate IdP must be accessible from the end user's desktop.
Got more juicy tidbits to add or feeling the itch to sprinkle your magical feedback dust? Don't be a stranger – drop a line, a joke, or even your favorite recipe! Feel free to leave a comment 📣
- SAP Managed Tags:
26 Comments
