Lightweight Directory Access Protocol (LDAP)

LDAP is the "old rabbit" under the authentication and authorization protocols. It is a protocol that allows you to query and change information in a so-called directory service. Known directory services are Microsoft Active Directory and Red Hat Directory Server.

The great disadvantage of direct authentication with LDAP is that authentication can always only be checked with a password. So if you connect an application server via LDAP, the application must accept the user's password and check it against the LDAP server. If one of many applications is compromised, the user's passwords are also compromised. Single-Sign-On with tokens was invented as a solution for this problem, for example SAML or OpenID Connect can be used.

Security Assertion Markup Language (SAML)

The SAML protocol is protocol for single-sign-on. It allows an application to register a user without even the identity the user must check. This task is assumed by the so-called identity provider, i.e. the IAM system. SAML comes from 2001 and based on XML, HTTP and cryptography. Over the years, vulnerabilities in SAML or SAML implementations have been repeated discovered. In particular, XML parsing and cryptographic validation are complex and susceptible to errors, but very relevant to security.

With the Artifact Binding you can massively reduce the attack area, because not only cryptography is left. correctly implemented, the procedure is considered safe. In many large companies, SAML is the standard. Since there are many configuration parameters, you should pay attention to enough time and the right staff are provided for the necessary care. There is an overview OWASP SAML Security cheat sheet .

OpenID Connect

OpenID Connect is also a protocol for single-sign-On. It dates back to 2014 and is significantly newer than SAML. In design, SAML was learned from problems and a procedure, equivalent to Artifact Binding, was made mandatory in the protocol. Unlike SAML, the protocol does not rely on XML, but on JSON and an REST API.

OpenID Connect is also available Note some things in configuration :

You should always use the Authorization Code Flow (for User) or the Client Credential Grant (for Applications). Proof-Key-for-Code-Exchange (PKCE) can combat attack scenarios where an attacker steals the authorization code. Overall, we would provide the privilege of SAML with new implementations, as it is significantly less complex and has already been designed safer from scratch.

OAuth 2.0 Token Exchange

In complex system landscapes, it occurs that a user (browser) does not interact directly with an application, but that communication takes place via another application. Imagine a dashboard that displays information from different system aggregated. The dashboard must talk to the applications "On-Behalf-Of", i.e. on behalf of the user. If the dashboard uses the token of the user to authenticate the user in other applications, this process is called "Token Propagation". A problem arises here: each of the applications could take this token and thus "black" in other applications on behalf of the user. The security problem that a compromised application concerns all other applications that we actually wanted to fight through the Single-Sign-On protocol is back.

The solution for the problem is simple: The dashboard exchanges the token in the IAM system for another restricted token, which is only valid for the target application, before the "On-Behalf-Of". The procedure was RFC 8693 - OAuth 2.0 Token Exchange standardised.

WebAuthn

A very sensible precaution against password leaks is the use of at least one second factor. The Google Authenticator or the sending of codes by SMS or email is widely used here. Meanwhile, however, the attackers also pull along and attack 2-factor authentication with phishing attacks. The only effective protection against phishing is that not only the user authenticates himself to the website, but also the website to the user. The cryptographic can be achieved. The FIDO2 project defines the WebAuthn protocol, which is now supported by the popular browsers. In addition, an internal or external authenticator is required, e.g. a Yubikey or a smartphone.

Kerberos

Kerberos is a single-sign-on authentication protocol that differs from SAML and OpenID Connect by not only spreading in web applications. It is the standard protocol spread in Microsoft Active Directory and therefore in many Windows-based corporate networks. Kerberos himself comes from the last millennium, the current version 5 from 2005 fixes many of the previously known security problems. In many IAM systems, authentication can be delegated to Kerberos. This means that employees who have registered with your workplace will also receive access to web applications connected via SAML or OpenID Connect.

X.509 Client Certificates

It is also possible to perform authentication on the Identity & Access Management System purely on a cryptographic basis. Trustworthy certification bodies are required. The central advantage here is that the secret does not have to leave the client's computer - the private key. This is different from a password-based authentication where the user enters the password in the login interface of the IAM system. However, challenges are the distribution of certificates, the secure storage of private keys, and the operation of certification bodies.

System for Cross-domain Identity Management (SCIM)

SCIM is a protocol that is not dedicated to authentication. It serves to synchronize users, attributes, groups and similar to various applications. If an office employee is hired in a company, an account can be created in Microsoft Office 365 and provided with the necessary rights. The user can be found by other employees in Office before he first logged in. If the employee leaves the company or changes to another profession, this user can be automatically deleted from Office with SCIM. In a plurality of applications, in particular as SaaS, this method is very helpful.

Remote Authentication Dial-In User Service (RADIUS)

The client/server protocol RADIUS serves to authenticate, authorize and account a network service. A RADIUS client sends a request for a Network service to the RADIUS server. This authenticates the sender on the basis of the associated access data (typically username & password). In addition, directory services connected to the RADIUS server, such as a LDAP Server used. The request is then authorized by the server, i.e., whether the user access to the requested network service and send a corresponding answer to the client. These functions are RFC 2865 - Remote Authentication Dial In User Service (RADIUS) specified.

In addition, accounting functions can be used to calculate, for example, the use of the network service, or to check compliance with certain quotas. To this end, the client typically a start message for accounting to the server, as well as periodic update messages that inform the server about the session still open. After termination the session is a stop message to the server. These functions are RFC 2866 - RADIUS Accounting described.