SAML stands for Security Assertion Markup Language

SAML provides one single unified login for all of a user’s accounts and services. Take your Google Account as a simple example. There was a time when as a customer of Google I had to log in to each of these applications separately. They then introduced accounts.google.com to unify login access for Single Sign-on (SSO). 

Instead of logging in separately to your calendar, your Gmail, Drive, Docs, Chat, and so on (all different applications certainly behind the scenes at Google) one login would authorize all five... or fifty, as the case may be. 

This type of Single sign-on for customer-facing applications is what is now the norm. Regardless of how many systems a company might be using behind the scenes, a customer should have one login for systems that the company controls. It’s a massive timesaver that removes the inconvenience of coordinating dozens of different authentications and passwords.

Another common use case for SAML is to help internal IT teams centrally manage access to tools and admin panels. So if someone leaves the company, the IT manager can shut off their account and they’d no longer have access to a number of resources.

At Bear Group, we’ve used SAML in this way so that users on the company network, who are in an admin group, also have access to their website administration panels. It's very useful when your team is big or highly distributed.

"Step-by-Step"

SAML runs as a stand-alone application typically on its own server, and other systems then connect to it for authentication. So for systems in your control, where you can change authentication methods, you can set up SAML as your Identify Provider (IDP).

Here is a simple guide for how to set up SAML for the systems in your control for your users.

# seting up idP 

$ fin project create

cd

fin composer require simplesamlphp/simplesamlphp mv docroot www && cd www ln -s ../vendor/simplesamlphp/simplesamlphp/www simplesaml

1. fin project create 
2. name 
3. 14 for static html 
4. cd <name> 
5. fin composer require simplesamlphp/simplesamlphp 
6. mv docroot www && cd www 
7. ln -s ../vendor/simplesamlphp/simplesamlphp/www simplesaml 
8. configure idP 
9. cd ../vendor/simplesamlphp/simplesamlphp 
10. ls config 
11. observe that it is empty 
12. cp config-templates/{authsources.php,config.php} config/ 
13. mvim config/config.php 
14. simplesaml gets confused by reverse proxy, doesn't know about port or https status, add at top: 
15. $_SERVER['HTTPS'] = 'on'; 
16. $_SERVER['SERVER_PORT'] = '443'; 
17. make sure baseurlpath matches your symlink if you used something other than simplesaml 

Conclusion

That’s really all there is to it. Once set up, it typically “replaces” the login experience for your connected applications, and of course, it can support as many logins as your database can store.  Once implemented, your users will be able to operate more efficiently, and your IT department will see a lot fewer forgotten password tickets. Everybody wins.