The handling of identification issues within an information technology company is known as identity and access management (IAM). IAM might refer to the team or the tasks that the team is responsible for. IAM should ideally be a centralised team, however owing to past events, political climate, or organisational design, this isn’t always feasible.
IAM can encompass managing user repositories, password policies, user authentication, authorisation of users and systems, user provisioning, auditing identity systems, and other issues.
Authentication
The act of verifying one entity’s (the Principal’s) identity to another is known as authentication (the System). The System must authenticate the Credentials the Principal supplies using an identity system of some kind (including User Repository, Federation Server, or other). Information on Users (Principals), their Credentials, Groups, group membership, and other user attributes are all contained in a User Repository.
The three main types of authentication procedures are listed below.
Something You Know: These criteria for authentication demand that the user remember and provide something they are aware of, like a password or Personal Identification Number (PIN).
Something You Have: In this case of authentication, the user is required to present proof that they are in possession of a physical object, such as a hardware token, smartphone, or smart card.
Something You Are: This technique of identification is based on a biometric characteristic, like a fingerprint or palm print, that is unique to the individual.
Types of Authentication Method
Choosing the correct type of authentication method is crucial as its not a one size fits all but ultimately this will be based on Security, Cost, Convenience / Ease of Use, Effort of Implementation, Ongoing Maintenance, Phone-based or Not.
Below are well known Authentication Methods.
AUTHENTICATION METHOD: SECURITY QUESTIONS
Challenge Questions & Answers are one of the original and older methods of
authentication. Users provide answers to previously enrolled questions.
The enrolment is completed by either an admin or the user during the first-time logging
into the system.
AUTHENTICATION METHOD: SMS OTP
The SMS delivery method (often referred to simply as ‘phone’) involves sending an SMS
text message to an enrolled mobile phone number. This SMS text message contains a
One-Time Passcode (OTP) that can only be used once to validate the user for a specific
action
AUTHENTICATION METHOD: EMAIL OTP
The Email OTP delivery method involves sending an email to an enrolled email address.
This email contains an OTP to validate the user for a specific action
AUTHENTICATION METHOD: MOBILE AUTHENTICATOR APPS
These applications generate a Time-Based One-Time Passcode (TOTP) and are installed
on the user’s device. When authenticating the user will be prompted to locate and open
the app on their device and then enter in the TOTP that is shown
AUTHENTICATION METHOD: PUSH NOTIFICATIONS
A push token is an ‘out-of-band’ second factor tied to a mobile device. This second factor
allows end-users to confirm or deny an authentication request by interacting with their
mobile device in real-time. No codes need to be remembered – just tap yes or no on the
screen to confirm the authentication request.
AUTHENTICATION METHOD: FIDO2 WebAuthn Hardware Tokens
FIDO2 (AKA WebAuthn) differs from FIDO U2F in that it is designed for a passwordless
approach to secure authentication. Functionally, FIDO2 tokens support the same usage
as FIDO U2F, though utilizing a different industry standard and browser-based API. FIDO2
Tokens support one of two usage types: Click to Authenticate or On-Device
Authentication. Click to Authenticate requires a tap/click of the token while On-Device
Authentication detects the FIDO2 request and automatically responds, allowing the
authentication action to proceed without any additional actions from the user
AUTHENTICATION METHOD: WEB-key (Identity-Bound Biometrics)
WEB-key is an enterprise-grade Identity-Bound Biometrics platform. IBB
creates a centralized unique biometric identity that can be used to verify you anywhere.
The primary method for capturing the biometric is by using a fingerprint scanner
AUTHENTICATION METHOD: MobileAuth (Identity-Bound Biometrics)
MobileAuth is an easy-to-use MFA mobile app with no new hardware required
and a fast QR code registration and enrolment process that can be completed in
seconds. MobileAuth offers PalmPositive as an authentication method and form of
Identity-Bound Biometrics which uses a simple palm scan to authenticate the individual
AUTHENTICATION METHOD: Integrated Device-Based Biometrics
Integrated device-based biometrics refers to biometric methods where all processing,
matching, and authenticating of the biometric is completed on the device. This includes
methods such as Touch ID and Face ID on iOS devices, biometric authentication on
Android devices, and Windows Hello on Windows devices
Single Sign On
Single Sign On (SSO) refers to the usage of the user’s identity to grant access across numerous Service Providers and is a feature of an authentication technique. SSO enables the usage of a single authentication procedure across numerous systems (Service Providers) within a single business or across many organizations (controlled by a single Identity Provider, Directory Server, or other authentication method). This solitary authentication method might be:
- a system that creates and distributes a trusted token to applications for authentication purposes, such as an LDAP server, Active Directory, database, or similar directory server.
- The process of using a password manager to sign into applications is sometimes referred to as SSO.
- a single set of login credentials across several systems (likely with some sort of asynchronous password synchronization system).
- Through Federation – See below.
In order to give the same login credentials across systems, Single Sign On (SSO) deals with authentication and the technical interoperability of the actors involved.
Types of SSO Protocols
A user can access various applications using single sign-on (SSO), which enables the use of a single set of login information, such as a username and password or even multi-factor authentication. This is an identity federation architecture, often known as federated identity management. Most applications depend on open standard protocols to specify how service providers (SPs) and identity providers (IdPs) can exchange identification and authentication data with one another in order for SSO to function.
Let’s take a look at the main SSO protocols in use today.
Central Authentication Service (CAS)
Shawn Bayern of Yale University created CAS, which is different from standard SAML SSO in that it uses server-to-server communication. While the final verification is conducted through a back-end connection between the CAS server and the Service Provider, the token request is initially initiated by the Client Machine. Because it relies on that additional, more direct verification, CAS is a common SSO protocol used in educational institutions. The SSO token does not exchange credentials, much like SAML.
Shibboleth SSO
Shibboleth is a further SSO protocol that is frequently used in educational institutions, particularly in cases when a large number of institutions are federated to share software and/or services. Shibboleth is based on SAML, but employs Discovery Service to enhance SAML’s handling of data from a user perspective.
Shibboleth is a further SSO protocol that is frequently used in educational institutions, particularly in cases when a large number of institutions are federated to share software and/or services. Shibboleth is based on SAML, but employs Discovery Service to enhance how well SAML organizes data from a variety of sources. Shibboleth also assists in automating the parsing of metadata for handling security certificate updates and other configurations that may be established by individual institutions within a federation.
Cookie-Based SSO
Works by transmitting user credentials from the browser to the server using web-based HTTP Cookies without the user’s input. Existing client machine credentials are captured, encrypted, and then transferred to the target server as a cookie. The cookie is delivered to the server. The credentials are extracted from the cookie, decrypted, and verified by the server against its internal user directory.
Claims-Based SSO
A claims issuer that is well-respected by numerous parties creates claims (also known as “assertions”). Typically, claims are contained in a Security Assertion Markup Language (SAML) token that can be delivered across the network (SAML).
NTLM-Based SSO
A user doesn’t need to provide their password in order to demonstrate that they are familiar with it. NTLM accomplishes this using a challenge and answer protocol that first establishes what NTLM variants and encryption techniques the client and server can both support. After that, the user’s password is cryptographically hashed and sent to the server needing authentication.
Kerberos-based SSO
Users can log into their Windows domain accounts with Kerberos and then get SSO to internal applications. In order to use Kerberos, a user must be connected to a central Key Distribution Center (KDC). Each Active Directory domain controller in Windows serves as a KDC. Users must first authenticate with the KDC before they may request encrypted service tickets from it for the services they want to utilize, such as web servers. With SPNEGO, this occurs automatically in all popular browsers (see below).
SPNEGO-based SSO
There are situations where the client application and distant server are unaware of the different methods of authentication that are supported by the other. The SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) can then be used to determine what mutually available authentication techniques there are. These systems may use NTLM and Kerberos for authentication.
Reduced SSO
Reduced single sign-on is frequently used to reduce the number of times a user must enter their login information to access various applications. Reduced SSO also provides a method to ensure that a user is not signed on without providing a second factor of authentication, which is required for essential applications.
Enrolment-Based SSO
When connecting into a website, a user has the option of having their login information stored there permanently. This is done by setting an encrypted cookie with the user’s credentials on the user’s computer for that particular web browser. This cookie is persistent over different browser sessions and system restarts, although it will expire after a predetermined time. The server identifies the cookie the next time the user visits the page, decrypts it to acquire the user’s credentials, validates them successfully, and totally skips the login screen.
Form-Filling SSO
Form-filling enables the safe preservation of data that would otherwise need to be entered into a form. This technology will remember/store all pertinent information for users who frequently fill out forms (particularly for security access) and secure it with a single password. The user just needs to remember one password to access the data, and the forms can be filled out automatically thanks to form-filling technology.
Federation
IAM includes Federated Identity Management as a subfield, but the same team(s) often supports it. In a federated SSO, the players are spread across various organizations and security domains. Federation’s objective is to enable the sharing of security principal identities and attributes across trust boundaries in accordance with predetermined policies.
In order for trustworthy third parties to verify against user credentials without actually seeing them, federation, the trust relationship between these organizations, must address where the user’s credentials are actually stored.
There are a number of different protocols that can be used to establish the federation relationship, including but not limited to:
SAML
Two popular SSO implementation alternatives are Web Services Federation (WS-Fed) and SAML Security Assertion Markup Language (SAML). These protocols share information about the user, the IdP, and the app via XML files (the service provider).
OpenID Connect
Based on the OAuth 2.0 authorization standard, OpenID Connect (OIDC) is an authentication and authorization protocol used for customer-facing single sign-on. JSON Web Tokens (JWT) are used by OIDC for authentication, and it integrates with one or more identity providers.
LDAP/AD
A protocol called Lightweight Directory Access Protocol (LDAP) gives users access to a directory of credentials. It utilizes the LDAP Data Interchange Format to share data (LDIF). An LDAP directory can be shared between various programs. When Active Directory (AD) and LDAP are used together, user IDs can be stored on the main AD server, and apps can send authentication requests to the LDAP/AD server.
Conclusion
The majority of businesses want to stop users from griping about having to remember numerous passwords and steer clear of the difficulties the IT department has when attempting to maintain numerous user repositories. Single Sign On using a well-known Identity Provider (idP) product in the enterprise arena should be used for all end user authentication. In other cases, the same is generally accurate as well. Similar to this, federation relationships should be a part of SSO in the enterprise space with actors outside of the local organization. It is recommended to use federation ties between systems in various organizations.
How Can ITM Help You?
IT Minister covers all aspects of Cyber Security including but not limited to Home cyber security managed solutions to automated manage Threat Intelligence, Forensic Investigations, Mobile Device Management, Cloud security best practice, Enterprise Network & Security Architecture, Application Security Testing, Identity and Access Management (IAM) and Cyber Security training. Our objective is to support organisations and consumers at every step of their cyber maturity journey. Contact Us for more information.