Child pages
  • OpenAM out of the box authentication modules
Skip to end of metadata
Go to start of metadata

There are 27 Authentication Modules out of the box in openAM.  Here the list and a basic description:

    • Active Directory: Provides authentication with user/password stored in Active Directory.
    • Adaptive Risk: Implements adaptive risk based authentication. This module measures the risk associated during an authentication event and based on a score it can trigger the use of an additional authentication module to request for additional credentials.
    • Anonymous: Provides anonymous authentication, i.e. non authenticated users, but nevertheless treated specially as non-authenticated.
    • Certificate: Provides authentication with an X.509 certificate stored in a Public Key Infrastructure (PKI) Infrastructure.
    • Data Store: Provides authentication with user/password stored in the current configured user data store.
    • Device Fingerprinting (two modules):
      • The Device ID (Match) module provides device fingerprinting functionality for risk-based authentication, by collecting information about client device locations, fonts, plugins, and more through their browsers. This module does not stand on its own in an authentication chain, as it uses authentication information from a service to validate a username. 
      • The Device ID (Save) module saves a user's device profile. 
    • Federation: Used in conjunction with the federation framework to configure SAML2 as a Service Provider.
    • ForgeRock Authenticator (Push): Provides a way to send push notification messages to a device such as a mobile phone, enabling multi-factor authentication.
    • ForgeRock Authenticator (Push) Registration: Provides a way to register a device such as a mobile phone for multi-factor authentication. 
    • HOTP: An HMAC one-time password (OTP) authentication module that can send an OTP via SMS or email. Typically used as a second factor authentication.
    • HTTP Basic: Supports the credentials to be sent with HTTP Basic authentication.
    • JDBC: Provides authentication to a relational database that can be accessed through a JDBC driver.
    • LDAP: Provides authentication with user/password stored in any LDAP v3 compliant Directory Server.
    • Membership: Supports self-registration and authentication at the same time.
    • MSISDN: Uses the Mobile Subscriber ISDN of a GSM or UMTS device that can been passed through a gateway.
    • OATH: Supports any OATH compliant device (hard or soft) able to generate HOTP or TOTP tokens. For example it supports smart phone token generator applications that are OATH compliant. The module which supports smart phone token generator applications is a separate version to the main OATH module, and is named ForgeRock Authenticator (OATH).
    • OAuth 2.0/OpenID Connect: Supports authentication to any OAuth 2.0 Authentication Server (Provider), such as FaceBook, Google, MSN, or a ForgeRock Access Management OAuth 2.0 Provider.
    • OpenID Connect (ID Token Bearer): Uses token bearer.
    • Persistent Cookie: Creates a persistent cookie after authentication that can survive browser restarts.
    • RADIUS: Supports RADIUS Authentication.
    • SecurID: Supports authentication with SecurID dongles by accessing an RSA SecurID Server.
    • SAE: Secure Attribute Exchange. Works in conjunction with SAML 2.0 federation to automatically share attributes that can be added to the Identity Provider (IdP) by legacy applications.
    • SAML2: Supports integration of SAML 2.0 single sign-on and single logout into an authentication chain.
    • Scripted Module: An authentication module in which the logic can be expressed using JavaScript or Groovy. It eliminates the need of creating a java class.
    • Windows Desktop SSO: Supports both Integrated Windows Authentication (IWA) and any MIT Kerberos Key Distribution Center through the use of SPNEGO in the web browsers.
    • WindowsNT: Supports authentication to a Windows NT Server.
    • WSS Auth: Used in combination with WSS Security.


In addition to these Authentication Methods, OpenAM provides an SPI (Server Provider Interface) to create bespoken methods that can address specific needs for integration with other Authentication Points or credential validators. Example of third party integration is the OpenAM YubiKey authentication, Hitachi Finger Vein Authentication module, etc


  • No labels

6 Comments

  1. The list seems to currently miss two modules:

    The Device Print module is a device fingerprinter. It collects information about client device locations, fonts, plugins, and more through their browsers. This module does not stand on its own, as it uses authentication information from a service to validate a username. The Device Print module then validates other characteristics of the user's system. 

     WSSAuth: used by the WSS Policy Agent as part of the web services authentication process. 


  2. Unknown User (ytheva)

    Can you please explain me the main differences between the ldap and datastore authentication modul?

    Which modul would you use if you have a OpenDJ?

    Thanks

  3. Unknown User (ytheva)

    Hi Matthias,

    thanks for your response.

    Thanks for the link to the docu, unfortunately i dont see any clear statements.

    What are for you the main characteristics between both modules ?

     

    1. You may first want to check what the "Data Store" in OpenAM is.

      In contrast to all other authentication modules, the "Data Store" Module does not define any connections to an external credentials store, but simply referes to the connection defined in the "Data Store" configuration. 

  4. Unknown User (jpayanides)

    Hi,

    Is it possible to authenticate users on GNU/Linux systems with sssd ? So does Redhat IdM and this allows to also pass a SELinux context and sudo permissions to the opened session. Can OpenAM provide such a feature and if it can, how to configure it?

    Thanks!