No one really likes to remember passwords. You’re probably in one of two camps – either you use the same password everywhere just to avoid needing to remember a variety of complex phrases, or you, like me, use a password database to store them (in which case, I only need to remember the password to that database so I can look up every other password). In either case, the end goal is to have the need to remember only one password.
Single Sign-On (SSO) has been around for quite some time, allowing organizations to federate their authentication and grant access to numerous platforms and applications while only requiring a user to remember one password. The value of SSO is really solely based on how many resources the user can access through it. For example, if SSO only gets you into Active Directory and, say, SalesForce, it has marginal value. But if you have that same SSO authentication providing the basis for access to everything a user needs, it has tremendous value, right?
So, enter the Security Assertion Markup Language (SAML), or more specifically today, SAML 2.0. This standard allows applications to authenticate users based on sessions in a completely different context (that is, accepting the authentication of an SSO platform and allowing access). It does this through the passing of some digitally signed XML files that prove the identity of the user has been confirmed by your SSO.
Now, normally the use case for the combination of SSO and SAML is to access an application and its’ resources. But there’s another use case that should be considered – one where users can offload management tasks from IT to improve organizational security and user productivity. We’ve previously made the case that IT can’t (and shouldn’t) be managing security alone and should employ the assistance of users. By adding this to the SSO mix, we increase the value of SSO, while simultaneously increasing the security of the network as a whole.
One of the barriers to adoption for some organizations is the need for every application a user touches to integrate with their implemented SSO environment. So, SAML helps open the door to allow management applications, like Imanami’s GroupID, utilize – and be utilized by – SSO platforms to grant users the ability to take tasks normally performed by IT and put them in the hands of users. Take the following two examples:
- Password Self-Service – rather than resorting to simple challenge questions to identify a user, GroupID can use external authenticators, such as Google, to reset a password. While that may seem a bit odd at first, think about it – if a threat actor wants to attempt to reset a user’s password (which they don’t have in the first place), what’s the likelihood they have that same user’s personal Google account password?
- Group Management – users that have been delegate authority to manage group memberships can be validated via an SSO platform rather than just AD, increasing user productivity and maintaining organizational security.
We live in a world today where, for some organizations, a unified logon is not just a reality, but a requirement. SAML provides a way for solutions like Group ID to make both IT and users more productive while maintaining the security intended when implementing SSO.
Jonathan Blackwell
View ProfileSince 2012, Jonathan Blackwell, an engineer and innovator, has provided engineering leadership that has put GroupID at the forefront of group and user management for Active Directory and Azure AD environments. His experience in development, marketing, and sales allows Jonathan to fully understand the Identity market and how buyers think.