Welcome, everyone. We'll give it just another thirty seconds here before I start. Thank you for taking the time to join. We'll get started momentarily. Wait until the clock hits noon. Awesome. Let's go ahead and get started. It is noon, so I wanna be respectful of everyone's time here today. And with that, my name is Alex Manning. I am the managing consultant for the Americas division here at Exciting, and I will be the moderator for today's webinar session. Prior to getting into the topic today, I'd like to set some ground rules for the webinar. For today's webinar, all of the participants' microphones and webcams will be disabled due to the platform settings. If you have any questions during the session today, please submit them via the chat. We will do our best to address as many questions as possible at the end of the presentation. If we run out of time today, Carson will follow-up as soon as possible after the webinar and provide responses to the group. For the webinar series at Exciting, we are providing a five part webinar series. This is part three of that series. The webinar series is themed around March Madness. We're calling the series Security Madness. For those of you that may be unfamiliar with March Madness, March Madness is a college basketball tournament that occurs in March in the US, and it's one of the most exciting exporting events that occurs in March. Typically, this is due to the fact that this is a single elimination format tournament. And so with a single elimination format, this leads to a lot of, upsets. It leads to a lot of Cinderella stories and dramatic finishes, if you will. So it's a very entertaining event in March, and so we wanted to try and relate SAP security and some of the topics in that space to this event that's occurring in March. And so for security madness, and for the webinar series, even though March may be all about basketball, here at Exciting, we know where the real madness happens, and that's in cybersecurity and in SAP security. And just like in March Madness tournament, where the underdogs arise, defenses get tested, and the unexpected happens, security is a game of constant strategy, agility, and risk management. In this March Madness inspired webinar series, we'll take you through the biggest threats, the best defenses, and smart plays to keep your system secure. Because in the world of cybersecurity, every access point is a potential fast break, every vulnerability is a full court press, and bad actors are always looking for their buzzer beater moments. Join us as we break down the bracket of threats, build a winning security strategy, and help you really slam dunk your security goals this March. For today's webinar, we'll be looking at and focusing on the future of SAP SSO in the cloud era. And as SAP continues its fast break toward the cloud, the game of authentication and single sign on is rapidly evolving. Just like in March Madness where teams must adapt to new challenges and play styles, businesses today face the task of securely integrating both on premise applications and SAP cloud services without slowing down operations or leaving vulnerabilities exposed. To stay in the game, organizations need to be agile, flexible, and future proof authentication strategies, one that protects access, eliminates unnecessary friction, and ensures a seamless transition from legacy systems. This is where SAP Cloud Identification Services and SAP Secure Logon Service for SAP GUI come into play, acting as your MVP, if you will, for secure authentication in a hybrid SAP landscape. So how do you build a winning authentication strategy without getting stuck in the past? Well today to break that down for us, we have our expert on the call in SSO, Carson Ault. He is the head of the IAM division here at Exciting with over fifteen years of experience as it relates to SAP SSO. And so Carson is going to coach us through the best plays, sharing practical insights on how to run a smooth transition, eliminate weak points, and really secure your SAP environment like a championship team. And so with that, let's get ready to level up your SSO SSO game, and I'll hand over the presentation to Carson. Carson, the stage is yours. Great. Thank you, Alex. Thanks for the handover. And then all has been said. So introduction has done as well. That's great. So I'm Carsten. I'm relocated here at Exciting in Germany. Yeah. And I'll I'll also like to welcome you to this, third game in our security madness series. This time about authentication and single sign on in hybrid landscapes and how a future proof single sign on looks like today. So I've been working with single sign on since many years now. Did a lot of project in that space. And, yeah, to do to be honest, it's still my one of my favorite topics because it's highly technical. It also extends beyond, SAP. So it involves a lot of different stakeholders in such projects, like people from from SAP, people from IT, you have architects, you have networking people, you have Microsoft is involved. You see, security responsible. And that's always something new you can learn from that from that kind of projects across these different areas in an organization. And I I want also to stay up to date when it comes to the latest technologies. Yeah. That's very important and to make such projects very interesting. With that being said, let's take a look at today's agenda. Yeah. We all know that, as Alex said, SAP is moving towards cloud very fast. And also with that, authentication has evolved over the past years. And, that means a lot of customers, SAP customers, still use their sub GUI and, yeah, it's still around. But together with Fiori, with modern applications, increasing use of browser based applications like BTP services, and also soft as a service applications. And the challenge there is that you need kind of a holistic authentication in single sign on strategy and one that aligns also with the modern enterprise security requirements. And that's what we talk about today. So first of all, I'd like to cover some essential basics. I want to talk about what does, single side on really mean. So why is the first authentication step no longer controlled by SAP? So we will introduce the concept of primary authentication and also downstream authentication, and we will discuss multi factor authentication and potential risks with MFA. In the second step, we talk about what matters in modern enterprises. So, you know, we have a lot of cloud joint clients nowadays. We have virtual desktop infrastructure. We have managed devices. There's a zero trust approach anywhere, and you have a lot of new cloud based tools, identity providers that have to be integrated. So what's really a key requirement for modern workplaces today? The third chapter we talk about considerations for the implementation, but also challenges and lessons learned. So what are key requirements when it comes to implementing single sign on? And in chapter four, then it gets interesting, then we look at the single sign on solution, how they have evolved over the time, so how to achieve a seamless and secure authentication across GUI BGP software as a service applications using the SAP secure login service for SAP GUI and the SAP Cloud Identity Services. So these two services, from SAP, that's the main topic in this presentation. We talk about them. We talk about components, features. We take a look in the authentication flows as well, and then we wrap it up with an overview how it fit all together. I also provide some resources, some takeaways for that, and some links to some interesting blog articles. And then at the end, we have a Q and A session. So during the webinar, feel free to post your questions, in the chat. And maybe you have something in mind throughout the session. And we if we can't answer anything today, we can, of course, follow-up those questions afterward. Alright. So hope that's makes sense for you, and then let's start with the session and with some, introduction and and basics around around single sign on. I mean, we all know this. Imagine you start your workday, you log in to your computer, you authenticate with a password, maybe with an app, but then you sign in using sub GUI, You connect to your VPN. You access various cloud based applications, and each of those are requiring multiple authentication steps. And we also know the frustration of constantly having to log in into those systems of frequently changing the passwords. But one thing is really clear: we need to move away from password logins from these endless login screens. Makes work harder. It makes no fun at all and also introduces significant security risks. So these kind of legacy authentication models where each application manages authentication separately, manages credentials separately is no longer a modern way of authentication. It's outdated period. So we need to come up with a solution that works for both on premises cloud solutions in parallel and that's the topic for today. Today authentication has to be considered on an enterprise wide level. So whenever we talk today about SAP Single Sign On it's no longer just an SAP project. Because the system that technically really verify a user's identity, that's where the user has to authenticate once, is no longer an SAP system in the most cases. And I'll explain that in a moment what I mean by that, but for now let's make one thing clear. Single Sign On is more than just a password free login. There's a lot of, stuff behind the scenes. Yeah. Furthermore, authentication has evolved dramatically over the past decades, along, of course, with infrastructure, with security requirements, with modern applications that came up. A lot of stuff happened. A lot of authentication standards have been established throughout the years. And so today, yeah, securing GUI Fiori browser based cloud applications within a hybrid landscape is super critical. So single sign on is then the key to achieve both a secure authentication mechanism and also a seamless user experience. And that's if we break that down, let's say, for from a simple point of view, from from an end user perspective, at the end today we really have a sub GUI. Yeah. I know we all have a lot of SAP attendees today, so still you know what an SAP GUI is, and, I guess you use it every day. And we have a browser, and that's mainly it. Maybe we have some mobile devices that we use to access our applications, but if you break it down on a simple few, we use a GUI, we use a browser, we connect to our applications that are either running any brand somewhere, data center hosted whatever, or in the cloud. And we need to come up with a simple solution that covers, let's say, these basic application accesses and these protocols as well. So we come back to that picture at the end again and take a look how it looks like when we use a single sign on in this case. But for now, let's first talk a little bit about password related risks and also benefits that single sign on can bring. I think it's well known that over eighty percent of all hacking related breaches, today are caused by stolen credentials, by weak passwords. So there's a lot of crap happening when it comes to social engineering, when it comes to phishing. You know, you read it all the day. So why are we still relying on so many passwords when there are already better authentication methods available? So single sign on is the solution, and with that we can deactivate, we can remove, we can get rid of passwords. And from an SAP perspective, in the best case, we no longer have even a password as a user. And that also removes, the need for the user to manage, to remember, to to to somehow handle all these different kind of login credentials. And that solves some key challenges, and it brings a lot of benefits. Like, for example, it eliminates time consuming logins. It allows the SAP end user, but also the admins. That's a very important point. Privileged accounts, for example, no longer they need to remember multiple passwords. No longer they have to type it in, in a worst case without even using encryption. So we have a centralized credential management because login happens at a central location, which can be protected in a better way compared to many SAP systems. There's no need for introducing complex reset processes or even additional tools that help us to somehow reset our passwords. And also, single sign on improves compliance with audit with IT security requirements and, of course, allows us to use or make use of multi factor and strong authentication. So that's the idea of future authentication that is passwordless. It is using single sign on for almost any application, and we can make that future a reality for SAP hybrid environments by, yeah, digging into the already existing products and how they can work together and help you as a customer to, yeah, make use of it. But before we just, yeah, take a moment to understand the authentication flow with single sign on for those who are not dealing with that topic every day. This slide will keep it very simple. Yeah. If you want to dive deeper, feel free to reach out and check out our blogs. They dive into all the nice details, about how single sign on really works. But for now, there's something that it's called the primary authentication. So the idea of that is a user that wants to access any kind of an SAP application, normally ends up at the application server or the cloud application, whatever. You want to open a GUI, want to access to a Fiori launchpad or maybe a a kind of a cloud based application. And the idea of single sign on is that now the target application is using single sign on and has no idea who the user is at this stage. So it just tells the user I'm using single sign on, outsourcing the job of authentication is no longer my responsibility. Here, you have to go to the identity provider. Technically, that is a redirect using browser technology. So the user is now sent to another entity, And that is called, there's a term for that, the IDP, the identity provider. Yeah? So the initial authentication no longer happens within the SAP application. It is handled centrally by the IdP and that often is a non SAP component. And at this stage, it is crucial to recognize that the primary authentication is super critical because it's the only one authentication that verifies our identity. So just relying on credentials, username, password, would be no longer enough to secure or to ensure our security. So to in this case, to strengthen our primary authentication against the IDP, we also need to introduce additional factors of authentication, additional protection, and this is where multi factor authentication comes into play. It provides multiple layers. For example, we can have something that we know that's typically the first factor, username and password, but then we can introduce a second factor, For example, something that we have could be an authenticator app or a hardware token that we need to use in order to authenticate, but it can be also a third factor or a different kind of second factor. For example, a biometric like a fingerprint reader like Windows halo. Yeah. Stuff like that in combination, at least two factors. But there's more nowadays. So nowadays it's possible to not only perform multi factor authentication. So the the the idea is to check not just the user's identity, but also the authentication context. So the the information, the identity signals, the device integrity. Maybe there are lots of different policies like MDM policies that you want to check for company managed device and so on. So there's a lot of stuff possible and much better than any SAP component could do nowadays. Yeah. Because, you know, all these Microsoft tools or maybe other vendors like Okta, Ping Identity, they have focused on secure authentication. They know what to do, and and that's why the authentication should be handled by an external entity in a secure way. Okay? So now that we know we have authenticated there, we have verified our identity, maybe device as well, The IDP responds with an so called token. That's the idea that exchanges our login, our identity against the single sign on token, and that now this will will be sent to the user. So the user now gets his token to access maybe the Sudbury, the Fiori launchpad, or any kind of SAP cloud application. It forwards this token to the application, and the application then will, of course, need to check the token. So it's protected cryptographically. It has been validated. There must be checked if there's a trust between the identity provider and the SAP application. And then, of course, this token contains something to identify the user. That is the identifier that is often can be the user principal name, the email address, an employee ID, whatever. That helps to map that token to a technical user, to an application user in the SAP system, and then the user is logged in under this account and the session can start. That's how let's say primary authentication and then the downstream token based single sign on towards SAP really works, and that's doesn't matter if the application is running on prem or running in the cloud. Yeah. And the cool thing is that it's no longer matters if you use dialogue RFC like using the GUI or if you use a browser based application. It's all handled in the same way and that's really the game changer. So summarize that, we use no longer passwords. We use token based authentication instead of credentials. We no longer build own authentication. We delegate to the IDP. So SAP has no longer responded before authentication. We support with that modern Waze. We support zero trusts. We can perform device checks. We can integrate with third party solutions like maybe an Entra ID. We can make use of Intune of conditional access policies for all these nice MFA solutions or FIDO tokens. And, of course, everything is running smooth, is running in an encrypted way, using transport layer security and with strong cryptographic algorithms. But that's the idea of having a real secure holistic single sign on nowadays. In summary, primary authentication always step one. Very important. We have to protect the identity. It's not enough to just use username password. In the best case, we should use a password less authentication for this first step. And then as one as soon as we have the access token, the single sign on token, it's always considered as a downstream authentication. That is where single sign on really happens. Okay? That's a summary. So we can, using single sign on, provide access to all applications with a single login. And then applications no longer authenticate. They just verify the user's token, checking the integrity, authenticity, and so on. And everything is based on on the trust that you, of course, need to configure during the initial setup, but it's also no longer a rocket science to to set it set this kind of stuff up. Yeah. And, as we talked about the second factor, many companies believe that having MFA means they are secure, but, not all MFA methods are offering the same level of protection. For example, short message service based as MFA or SMS based MFA still widely used. I I know it by myself. Often, I work with customers, for customers, and they will be onboarding, and I just receive kind of an SMS as a second factor. I mean, you could use that, but it comes with serious risks nowadays. So hackers can intercept SMS using something called IMSI catchers that act like a kind of fake mobile tower with a stronger signal where your mobile device connects to, and then they can intercept and forward your your SMS without any issues. Yeah. They keep there are other tricks like SIM swapping and and so on. But at the end, SMS is one of the weakest authentication methods nowadays and should no longer be used. Yeah. We take a look at applications like, for example, Microsoft Authenticator, Google Authenticator, they are definitely better than compared with SMS. But are they a hundred percent safe? Answer is no. They they are not. Because even with OTP based access with one time passwords or push notifications that we most of us use nowadays, it is possible to steal credentials, via phishing attacks. So, for example, often we find ourselves in insecure public Wi Fis or, yeah, networks that we don't know, and there are a lot of bad actors that are using tools, man in the middle attacks, and proxies such as evil jinx. It's one of the worst hacking frameworks available, that allows us to steal the token. So, for example, hacker creates a fake login page that looks exactly like your Microsoft login screen, and there you enter your login credentials, your MFA, because it's forwarded to the real entity behind. You think it's real, and Evilginx just steals your access token. The the result of the proper authentication runs through the Evilginx as kind of a pass through proxy. So now the hacker has your access token and can log in without your username and password, without your MFA. As long as the token is valid, the hacker can, yeah, use your account. And since such session tokens can remain valid for hours, for even days, yeah, attackers can maintain access even after you have resetted your, maybe, your MFA process. I mean, of course, there are ways to mitigate these risks. We also use that here at exciting. So, we use conditional access. We use device based authentication. That means we can restrict logins only to trusted devices. That is first of all a very good measurement and the second is we can enable token expiration and re authentication policies. So we can reduce the validity period and we can enforce frequent authentication or re authentication. And that helps to protect. So that's still a good solution, but the most secure solution out there nowadays is really FIDO2 standard. So the passwordless authentication method that are using security keys or biometrics, like, for example, embedded in your devices. Yeah. Windows halo is one of them or even touch ID on the on the Macs. And unlike passwords or MFA or, stuff like that, FIDO must verify the real website. So it's the DNS name is embedded in the authentication process that makes phishing and that makes replay attacks impossible. So if you really want to, yeah, want to be secure and move beyond passwords, you should go for FIDO two authentication. Yeah. You should think about using FIDO two. That, of course, is supported either from your IDP side. Maybe Microsoft Entra ID supports that, but also the SAP solutions support FIDO two web authentication. I'm not talking here about any kind of hardware. Not we are not dealing with that, but it's just to let you know about a little bit more about background about these MFA technologies that are existing today in in the wide. Yeah. Alright. Short introduction about the topic in general. Now we know primary authentication, a little bit about tokens, and now let's take a look in what's changed and what organizations are really need today. So from our experience, many organizations, shifting towards centrally managed devices, stronger identity controls, as we talked before, to enhance security. So the traditional network as we know it, the boundaries of the network security model is being replaced by zero trust where identity signals, where device security matters more than just the network isolation or the Windows login. Yeah. So many companies no longer operate within a traditional perimeter where everything is neatly contained in an active directory domain like it was a decade back. Instead, authentication needs to adapt. Yeah. That's also, for example, when it comes to Kerberos authentication. Many of us or of our customers are using Kerberos authentication. It's still a good and a valid way to to to use single sign on. But these domains, these traditional Active Directory domains, they are fading more and more. You know, we see many companies that are moving to cloud only joint devices, workstations, and it marks the end of Kerberos because it's no longer there in the cloud. Azure or Android, there is no Kerberos anymore. And the shift from AD to Android also to a modern identity strategy is essential. So organizations need single sign on, they need multi factor authentication, but they also need policies like conditional access Intune talked about before. So EntraID often, at least at many of our customers, is seen as the central hub for managing user identities for device security in the cloud era. And, yeah, at the heart of all these SAP future authentication strategy is, of course, the SAP cloud identity services. It's a free foundational service, for modern single sign on. I will talk in a while about this service in more details, but, for now, just need to know that we can combine the sub GUI together with, yeah, browser based application, with cloud based application in, yeah, one way. That allows us to really, yeah, face the challenge of traditional legacy environments and combine it with modern authentication. However, we don't need to forget the traditional SAP GUI. SAPGUI is still there. It will be around for quite a while. So, we need to come up with a solution that also considers the SAPGUI. And it's a very old information you all know that, I hope so, that in the standards the dialogue, the direct protocol, and the remote function call the RFC is insecure. So it's a ASCII protocol. It's not protected on the network level. It is easy to steal credentials, to steal, information about the whole payload if you intercept the connection, if you listen to the tap, if you it's it's exposing by passwords by eavesdropping, for example. So you can say that if you log in without having any kind of security using the sub GUI, your password is sent like post postcard via the network, and anyone who is able to listen to the traffic, if it is wireless or wired, doesn't matter, can get in possession of your information like your username and password that you use to log in. So when we protect this channel using secure network communication, SNC, we can tunnel dialogue RFC in a secure way, and only then we can also allow to use token based downstream authentication, having a certificate or tokens like a Kavros token towards SAP. And we don't have to forget the GUI. That's the main point. So because all the other modern technologies are already covered with the cloud identity services. Okay. Before we take a look at the s SAP solution, I'd like to just cover some fundamentals, some project requirements, some challenges that we learned during our projects. I make it short. You can read all this or watch the recording later on anytime. That's a lot to read here. So first of all, SAP systems today are central to IT infrastructure. So they must be really secured holistically, and that means that the era of isolated approaches like silos is over it should be over, and SAP security has to be fully integrated into a enterprise wide security strategy. That's not so easy as it is said because still we have some CIOs, some IT guys that just have a look on, yeah, networking, traditional Microsoft stuff. But when it comes to SAP, they're often completely, yeah, clueless. And the challenge is raising awareness with the right stakeholders to have the c level support for such projects. Yeah. To to to, yeah, consider them to we need to enforce end to end encryption. We need to secure this hybrid SAP environments in the same way as we do for other enterprise applications. We need to shift from passwords to token based approach. That's crucial. Yeah. Because, you know, all these credential, theft, all these risks related to that, we can overcome those. And while I already told you that Kerberos is often in use, there are modern authentication methods like SAM, like OpenID Connect that allows a very much, or greater flexibility when it comes to authenticate the user. So there are zero trust models that demand stronger identity and device verification. MFA is absolutely essential. So there's a lot of stuff to consider. When it comes to end to end encryption, of course, it makes sense to start with that. So RFC dialogue, HTTP, everything has to be encrypted. Also, authentication has to be enforced at the communication level. That means also we have to consider in such projects reverse proxies, web dispatchers, kind of additional tools, VPNs. We also have to secure external access. We have to handle maybe also guests and partners, not only b two p b two p users or employees. So a lot of topics come together when you really take care of a holistic single sign on approach in in that space. And lastly, of course, the SAP common cryptographic library. It's the the the yeah, crypto library on the SAP back end side that still is required on your traditional ABAP, Netweaver, or S4HANA systems. That requires frequent updates beyond the standard patch cycle. That means we had some recent vulnerabilities that really highlighted the the need for continuous patching to prevent such security breaches. So all the keeping cipher suites updated and so on is really essential for for hardened operations of that. So it's an ongoing project. It's not just install and forget. Yeah. It's always you have to clean up after introducing signals and on. You have to get rid of passwords. You have to disable old legacy methods like some log on tickets, and then you have to also stay clean and regularly check if yeah. Check your check your environment and and, make sure you can stay stay clean in that that setup. Okay. Now let's take a look at the evolution from past to present. And, yeah, if we talk about the present, we have to talk about the BTP, as you can imagine. So it is always SAP sees the business technology platform and the portfolio around as the core. And one of the suit qualities, as we can see here, is a consistent security and identity management. And if we take a look at the CIO guide from SAP that you or some of you may be familiar with, there is one document that's called CIO guide about identity and access management. It's a very nice resource, by the way, for decision makers, for architects, for c level responsible. And there, you will find lots of information about the approach of SAP to standardize, authentication and identity management and using the cloud identity services, of course, which is a game changer as it now allows, yeah, subauthentication to fully align with a corporate IT policy just like it is for any other enterprise application. And that ensures a seamless login, secure access to GUI, to Fiori, to cloud based applications, and, of course, it simplifies the identity management or identity access management in the overall point of view. I know single sign on authentication is one part of a IAM, and I will talk about the identity services now in a minute. So really can recommend to take a look here in this CIO guide because it really underscores the importance of standardization, for I'm processes and and centralization of authentication as well. So I decided to use a different picture now, and compared with the one that we already are using all the time. So this one is from SAP. It's a very, very, current one, updated one. If you take a look here, you can see that the cloud identity services in general, let's start this way, is a group of BTP of Business Technology Platform services that allows you to integrate identity and access management between systems. So we have your applications here that is doesn't matter if this is cloud or on premise. Mainly we talk about SAP applications in the BTP, software as a service applications, or any prem. Yeah? And then we have four main services when it comes to the cloud identity services. The first one is the identity authentication service. That one is responsible for authentication and single sign on as the name implies. That's also called IAS. In contrast, the IPS or the identity provisioning service, that's the one who manages the identity life cycle, so including users and groups. You know, these are these SCIM based operations where you create, change, delete, update your user information throughout your application ecosystem. We have the identity directory that is more or less a central place for storing and managing users, groups, and nowadays also authorizations. And then there's a very new service that's called the AMS or authorization management service that's still in the works, I would say, that enables administrators to refine authorization policies or attribute based authorization policies for and that's mainly that's important for BTP based applications, so for CAP applications, but also for for the, secure, accessing the the the Cloud Identity Services administration console. So you can better refine access controls within the application, of the Cloud Identity Services. So it's a service that's integrated, that's bundled with many solutions from from SAP, that's pre configured very often. So you receive this at no cost, at no additional cost. So for example, it comes with success factors, or it is free if you are already a BTP customer. So as soon as you have your contract, your global account, let's say, with SAP, you are allowed to use two tenants of this Cloud Identity services with no additional cost. And you can connect any cloud application from SAP and any on premise application from SAP there to manage your identity life cycle and to manage your authentication, and that's a good point. Yeah? So it is really it's essential in the overall setup. It is seen as a backbone for an IAM architecture. Yeah? SAP solutions integrate with that tool. For example, when it comes to authentication, IAS can integrate with an existing identity provider. So you no not have to authenticate here. You just forward your federate again to your Microsoft or to your whatever kind of third party solution you may have. Also, the user information is directly read from the central user store, from the identity directory service, or you can integrate an existing user store using the SCIM protocol, because this identity directory is also an API. You can connect to it using the SCIM API, and you can provision information from any kind of third party system to that system. So cloud identity service has a lot of functionalities, IAM functionalities built in, I have to say. But it's important to understand that are not that they are not aiming to replace a full featured identity and access management tool. That's not possible because many customers use that as a broker. Let's say they appreciate that identity services can be easily integrated. They they can use an identity provider. They can connect with an IAM tool of choice, and it reduces the efforts to manage and configure each single application manually or to even develop custom connectors when it comes to I'm to provision kind of cloud systems. Systems. Yeah? Managing all these JSON data transformations for each system. That's the idea of having this central hub, this cloud identity services in between. So it's for IAM in general, but here this presentation, the focus is on the authentication part, of course. Hope that makes it a little bit more clearer. Yeah. If we now talk about the single sign on back and now back then and now, we have to take a look on the SAP single sign on three point zero that certainly a lot of, SAP customers use nowadays. As we all know, a lot of projects will be, products will be end of maintenance, end of twenty twenty seven. That seems to be a doomsday for SAP customers. That means also it's, yeah, it's the product single sign on three. It will end, in, yeah, twenty twenty seven. We go out of maintenance mainly because it is using an underlying SAP NetViper as Java. And there's already a successor solution taking center stage. It's already there since last year, since twenty twenty three. Sorry. And that's the Secure Login Service for SAP GUI. That's really the product name, Secure Login Service for SAP GUI. It's a long name. And as the name implies, you can hear from that, it's a service for the SAP GUI. Because, you know, all the other applications today, they are handled already by using Cloud Identity services. So this service is not relying anymore on any kind of on premise component. So you no longer need the secure login server on the IS Java. Instead, it is consuming a BTP service. So all the functionalities have been transferred to the cloud. And I don't come up with a lot of SAP slides here, so you can find solution brief, release blocks, very good overview presentation, and a great article on the sub community about the whole flow and create YouTube video as well. Yeah. If you want to dive deeper into comparing single sign on three with the new solution, you can also read our deep dive blog on LinkedIn. It's a perfect resource to learn more, and it covers almost any information in this webinar, I would say. But, of course, we take a look a little bit a look on the components and then on the authentication flow. First of all, we still, of course, have a component that will be installed on the client side. So it is the so called secure login client that we all know from single sign on three that can be installed on Windows computers and on macOS. And, of course, we still have on the SAP side, on the back end side, on traditional s four systems. For example, we have the SAP common cryptolib, which still is the crypto library that handles all the SNC'd parts. So nothing has changed much on the client and on the back end. That's the good news. The the most, will happen on the BTP side. So it is the case that it's running as a service, as an instance on one dedicated, for example, a Cloud Foundry subaccount within your environment. So you can span up an instance of the secure login service for SAP GUI there, and it integrates it must integrate with an identity authentication service tenant. So they work together. So let's take a look. Makes makes it more clear at the whole chain. So there are a lot of entities involved in order to get our single sign on token. But, basically, the idea of of this is that the user is trying to access a NetWeaver application server or an Sfour system that runs maybe on sorry, on prem, but it must not be on prem. It can be also in the in the private cloud. It can be hosted by SAP with rides with SAP. It can be whatever kind of any prem system. As long as the user reaches the system using his sub GUI. Okay? So at this time, user has no token. So the idea is that now the secure login client comes into the game. And now the big the big change happens. A SecureLogin client now has an embedded browser. That's absolutely new now. So that means that the authentication no longer happens against any kind of on prem system, but it goes to your instance of the secure login service running in the BTP. And in turn, that service receives a request from a user. It's still an anonymous, and the user, must authenticate. So identity authentication service will authenticate the user here at this stage, or much better, it forwards again this request to your corporate IDP. In this example, it is a Microsoft Entra ID, but it can be any identity provider. Yeah. And here in step four, the primary authentication happens again. So all the nice features we talked about, like MFA, like device checking, like policies that you can perform, checks that you perform here, happens all in the corporate identity provider side, and the hopefully successful result will be transferred back to the IAS, will be transferred back to the service. And then there is another component as you can see. It's kind of the SAP trust center in the cloud. It's a managed service from SAP that technically issues the user certificate. So once this has been checked, authentication is successful, this service issues the certificate, which is a short lived, normally a day day daily certificate that comes back to the user's secure login client and then can be used for the SNC session in order to authenticate using single sign on based on SNC with a certificate. And that means, of course, now the primary authentication can be interactive. So you have to do something. You have to maybe use your authenticator to log in. It can be fully automated without even knowing that all these components are involved. You just click on your sub GUI, you're logged in. But you also can do more. You can maybe check for specific systems, have a different policy for for specific users, groups, systems where you enforce other kind of security mechanisms or enforce a stronger way of authentication. So it's absolutely flexible, and you can do a lot of a lot of stuff with that. Yeah. It by the way, it might I mean, I should, just mention that you can still use Kerberos with that, secure login service for SAP GUI. So this the client component is still capable of authenticating the user based on Kerberos the same way as the old solution. So you can easily transition. You can migrate to this new solution because the back end logic and the front end or the client is unchanged. Yeah. So a parallel operation is possible, and you can control the switch between the old and the new solution. And we already did that. So we already did quite a few successful projects and migrations with the new service. That's absolutely, not a not a big deal. So, yeah, that that all these these information about using such a lean cloud service, getting a short lived certificate that is issued built on top of the cloud identity services, on the identity authentication service, is really essential because it allows us to harmonize the flow using either sub GUI or any kind of cloud browser based applications. We have the same kind of login. Yeah. It's no longer separated, and that is really the game changer here. So from the user experience point of view, the initial authentication is always the same no matter which client he uses, yeah, to access the application. And that really increases user acceptance, and and it reduces a lot of complexity. So let's just summarize that. Let's take a look at, a very simple view again. But now we see there's a user, and that user either has a sub GUI or has a browser or mobile device, and he wants to access an SAP application anywhere. Yeah? Cloud on prem. Doesn't matter. And mainly, there are two ways. It's one ways could be dialogue RC based. That's not just the sub log on. There are other tools that use dialogue RC as well. Or it's just the HTTP HTTP application trans transformed securely via TLS. The idea of these applications is outsource the job, delegate to the identity authentication service in the BTP. Here the trust is already established or you can establish a trust during the setup. And then in turn, if you want, the IAS can again federate and outsource delegate outsource the authentication to an identity provider of choice. That can be any identity provider. Yeah? So it's also important to mention that you can have multiple identity providers connected to the IAS. For example, if you want to separate between b two b processes and maybe connect or federate with some partners or external, kind of business partners, whatever. So you can have multiple multiple, IDPs connected to your identity service. Let's come back to that picture. We we have, seen at the very beginning. Now we have the same point of view, and now we place in the middle in between the cloud identity services as a central hub, as a central, BTP service where every connection has to go through. Yeah. So mainly, we are using OpenID Connect, SAML two, and certificate based authentication. These are the three main technologies that we really use when it comes to Cloud Identity services in combination with the secure login service that we need because we still have SAP GUI. If you no longer have a SAP GUI in in use in your organization, that's not a problem. Then you just need the Cloud Identity Services. Yeah. Then Cloud Identity Services, again, most of the time, they integrate with an existing corporate IDP, and you can make use of all these nice features. That's mainly it. So that's what I wanted to tell you with that webinar, how easy and how simple it can look like. There's a lot of additional stuff. I don't go through these slides. No. Like, benefits of single sign on. We talked about that. I have some useful information about the secure login service, some pricing information, some some recommended procedures, yeah, the the steps that you can go through. You can all find it also in our blogs and articles. And there are a lot of nice articles. I have just provided you with a collection of those. There's one I've highlighted that I really recommend to read. And with that, we are just looking forward to your questions, maybe. Don't forget we have two two games left, game four, game five, when it comes to XCP and or exciting platform, security platform, XSP. And, yeah, with that being said, thank you for your attention, and I'm open now for q and a. We have five minutes left, and let's see if we have some questions in the chat. How does it look like? Yeah. Thank you so much for the presentation here. And just to look at some of the questions that we have in the chat, one question that we have is looking at the old world, are we able to manage HANA Studio and Eclipse access with single sign on? Is that something that you're aware of? HANA Studio, is still a special special application. Yeah. It's HANA cockpit. It's no problem. HANA studio, I have already integrated it with Kerberos authentication. But as far as I know, SAML should be supported there as well for the studio. What was the other tool? Eclipse, which is that ABAP development tool. ABAP for Eclipse is, as far as I know, it's an RFC based, front end application that can be tunneled through SNC and then works the same way like a sub GUI connection. So you can use make use of the new secure login service for that. Awesome. Thank you, for that response. Another question that we have in the chat is, how will authentication mechanisms work for nonhuman identities in the future? Well, nonhuman identities, NHI, I know this topic, but, honestly, that's not our focus. We focus here on business to business scenarios on a user, point of view, on a user centric point of view. Nonhuman identities like smart devices and all the other stuff like embedded industrial devices, of course, they need to also work with proper ways to authenticate and, yeah, there are a lot of ideas about how to handle that, and and also certificate vendors that, are in this game. But it's not our our main domain, so I would like to skip that question because I can't really tell you more about that. Okay? That's fair. No. That's fair, and, thank you for the response. At this time, I I don't see any other questions in the chat. Those were the only two, that I have at this point in time. Let me just refresh and double check. I mean, if you have some questions, just let me know. And any any at any time, you can also send us an email or contact me directly. No problem. Yeah. Thanks. Awesome. To be here today. Well, I think with that, we'll we'll call the we'll call it there for today. Thank you so much for taking the time to join today, everyone, and I I hope everyone has a great rest of their week. Alright. Thanks, Hugh. Thanks, everybody. Have a nice day. Bye bye.
