When applications are authenticated, user lists are added to those apps and used. On the network side, when accessing routers/switches, local usernames are created and used within those routers/switches. The problem is that all apps, All routers/switches have separate logins for all apps/devices as users. Whether you want to change your password, If people are leaving and new people are coming in, it’s not easy to change. User Lifecycle Management is hard. It can be easily done in a place where there are about 10 people, but in a situation where there are hundreds/thousands of people, this big issue becomes a job for Apps, System/Network people.
On the network side, they use Radius and Tacacs+ for Device Authentication and Identity Management. They connect and use it as AAA server from devices. I’ve written about AAA before; If you are interested, try to read again. As for enterprise applications, they usually use Directory Service and connect it to LDAP. Doing so separates Apps and IAM (Identity Access Management). Large organizations only have dedicated IAM teams. The Directory server is inside a private data center, so all the apps that run it must be inside the LAN/Intranet.
Now that the cloud era has arrived, all apps are no longer in your network. Some end up in their own IaaS and switch to better, simpler SaaS. Stop the Apps inside yourself and use SaaS easily. For example, instead of maintaining an HR system with Servers, Apps developers, and Sys engineers, they pay a monthly/annual fee and switch to using it. There is no need to worry about the Hardware / Network / Systems / Apps below. But every department doesn’t want to get married like that anymore, and we will switch to SaaS, and SaaS will expand as an organization as a whole. SaaS users have to create usernames for everyone. So, if an employee needs to use 10 SaaS, why not remember 10 usernames for those 10? User Lifecycle Management, which was the problem before, came back a week ago. So.. So how?? Of course.
Since SaaS are Cloud Apps, they are outside. Go through the internet. There is no problem. From SaaS, you can’t attack Directory Server with internal identities from the outside. Can’t pay directly. There will be trouble. In organizations, there are usually only Web Apps that come from the outside/internet. To solve that problem, In addition, Cloud SaaS will have to be somehow connected to your internal Directory service. Only then will the Centralize IAM level be returned to the previous level and User lifecycle management will be returned. That’s where SAML (Security Assertion Markup Language) comes in. SAML is OK Cloud SaaS, I am the Identity Provider and the IdP (Identity Provider) that will connect to the Directory server behind me. Since you guys are service providers, you are SP (Service Provider). On your side, there are still other IdPs to be connected. On my side, there are still a lot of SPs to be connected, so we need to have an Entity ID so that we can separate them from each other. In order to work together, we need to build trust. So give me your certificate and I will give you my certificate. If guys from my office come to your Apps/SP, don’t use local identity from you, redirect to me. If authentication is OK from my side, I will send it back to that side. In order to do so, I had to provide the ACS (Assertion Consumer Service) URL.
By using SAML and connecting IdP to SP, many IAM issues will be solved. But the difficult thing is that some Cloud SaaS don’t have SAML, and if they don’t work with your IdP, there are still small issues. So, if you are going to use a Cloud SaaS, ask if you do SAML Support, what other ways do you do IAM, etc. and choose to get them. I’m not asking others, but if you don’t have SAML on your side, make a SAML Frontend. If not, use OKTA and Jumcloud as Cloud IAM for IdP. For now, if you use SaaS, if you see SAML, you will know what it is and if you are interested, I think it is convenient to read it again.