What’s new in OpenAM 12

par | Déc 18, 2014 | Gestion des Identités, Sécurité, SSO

OpenAM 12 fixes a number of issues, and provides the following additional features.

source:

Major New Features

New Features for Users
  • User Self-ServiceOpenAM supports self-service user registration, device management and password reset – reducing costs and increasing customer satisfaction.
    Self-Service User Registration
    OpenAM now offers a user self-registration service through the XUI interface. Click the Register link on the Login page and enter an email address.OpenAM will email you to confirm your address, and include a link to a page where you can register your details, as shown below.

    For more information, see the Administration Guide section Configuring User Self-Registration.

    Trusted Device Management
    OpenAM allows you to manage a list of trusted devices from your Dashboard page.When you log in to the console, OpenAM determines if the device you are using differs from that in a stored profile. If there are differences, you will be asked to enter a one-time password.After the one-time password is verified, you can provide a name for the device and add it to the list of trusted devices.Trusted devices appear in the Dashboard when you log in, as shown below, and can be removed by clicking Delete Device.

    For more information, see the Administration Guide sections Hints for the Device ID (Match) Authentication Module and Hints for the Device ID (Save) Authentication Module.

    Authorized Application Management
    You can now manage your authorized applications (those that use OAuth 2.0 tokens) from the Dashboard link on the user page of the OpenAM console. In the Authorized Apps section, view your OAuth 2.0 tokens or remove them by clicking the Revoke Access link.
  • Social AuthenticationLog in to an OpenAM protected resource by using your existing social website credentials. OpenAM supports Facebook, Google, Microsoft, or any other OpenID Connect 1.0 compliant identity provider.

    The OpenAM administration console provides wizards for quickly configuring social authentication. For more information, see the Administration Guide section Configuring Social Authentication.

New Features for Administrators
  • New Policy EditorOpenAM policy configuration now supports applications. OpenAM applications act as templates for all the policies that govern access to the protected resources in your applications.When you create or edit a policy in OpenAM console for a particular realm, you first choose the application that the policy belongs to, and then create the policy or choose the policy to edit.The new policy editor user interface allows you to quickly create applications and complex authorization policies, using point-and-click and drag-and-drop operations.

    For more information, see the Administration Guide chapter Defining Authorization Policies

  • Policy Export and ImportYou can import and export policies to and from XACML 3.0 format files. Use the files for version control, or migration between OpenAM test and production instances, for example.For more information, see the Administration Guide section Importing and Exporting Policies
  • Extended Authorization SubjectsYou can now choose between an SSO token and an OpenID Connect ID token as the subject to evaluate authorization policies against. OpenID Connect ID Tokens can be used when there is no current user session, for example when an offline batch processing routine acts on behalf of a user.For more information, see the Administration Guide section Hints for the OpenID Connect id_token bearer Module
  • Scripted Authentication ModulesYou can create custom authentication scripts to gather knowledge about a user to help determine their authentication path. A scripted authentication module runs a script to perform authentication, making it easier than ever before to develop custom authentication modules.For example your script could make a call to a third-party proofing service to determine risk, and require stronger authentication depending on the context of the login request.Scripted authentication modules have access to the same data as other modules in the chain, can access user profile data during authentication, can make HTTP calls to external services, and are sandboxed for more secure operation. The scripts are stored in OpenAM configuration data, and so transparently available across OpenAM Sites. Server-side scripts can be written in either Groovy or JavaScript.For details on writing authentication module scripts, see the Developer Guide chapter Scripting Authentication.For details on configuring scripted authentication modules, see the Administration Guide section Hints For Scripted Authentication Modules.
  • Scripted Device Identification ModulesOpenAM 12.0 introduces new Device ID (Match) and Device ID (Save) authentication modules that support the ability to customize your device fingerprinting implementations.The Device ID (Match) Authentication Module uses the new JavaScript/Groovy scripting engine, and demonstrates how scripted modules can be used to add contextual intelligence to the login process.For more information, see the Administration Guide section Hints for the Device ID (Match) Authentication Module
New Features for Developers
  • REST STS for Token TransformationUse the RESTful Security Token Service (REST STS) to convert tokens in the various formats that OpenAM supports, such as OpenID Connect, X.509, and SSO, into a SAML2 token. Given the variety of token types in use today, it can be helpful to have a configurable service that transform tokens.For more information, see the Administration Guide chapter The RESTful Security Token Service
  • OAuth 2.0 and OpenID Connect 1.0 ImprovementsMake use of improved support of the OAuth 2.0 and OpenID Connect 1.0 standards, widely used in mobile and web applications. OpenAM rigorously enforces these standards, improving interoperability, and shortening development lead times.For more information, see the Developer’s Guide chapter RESTful OAuth 2.0 and OpenID Connect 1.0 ServicesOpenAM also supports the JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants (OPENAM-4394). This profile allows OAuth 2.0 clients to use JWTs for authentication and to request access tokens. For more information, see the Administration Guide section Authorization.
  • Fine-Grained Policy APIsAuthor sophisticated authorization policies by using OpenAM’s RESTful interfaces. Manage realms, applications, and policies, list application, condition, and subject types, and request policy decisions using the API, simplifying your applications and deployment.For more information, see the Developer’s Guide chapter RESTful Authorization and Policy Management Services
  • GSMA Mobile Connect SupportOpenAM now includes support for GSMA Mobile Connect, a profile of OpenID Connect 1.0.Mobile Connect lets you authenticate with a mobile phone, regardless of the service or the device on which it is consumed. This allows mobile network operators to serve as identity providers for their customers.For more information, see the Administration Guide section Using OpenAM with Mobile Connect.
  • REST API VersioningOpenAM now assigns REST API features version numbers, to help with backwards-compatibility. You can specify the required version to use when making a call.Use the versioning to insulate your REST clients against breaking changes when upgrading an OpenAM instance.For more information, see the Developer’s Guide section REST API Versioning.
  • Support for the Latest PlatformsOpenAM supports the latest platforms such as Java 8 and Apache Tomcat 8.For more information on OpenAM requirements and supported versions, see Chapter 2, Before You Install OpenAM 12.0.0 Software.

1.2. Additional New Features

  • Audit Logging to SyslogOpenAM now supports logging audit messages to syslog.For more information, see the Administration Guide section Audit Logging to syslog in the Administration Guide.
  • Persistent Cookie from Client IP IssuedThe Persistent Cookie module has been enhanced to be able to enforce that the persistent cookie can only be used from the same client IP to which the cookie was issued.
  • CORS Support for OpenAM APIsOpenAM now supports cross-origin resource sharing (CORS) to allow requests to be made across domains from user agents. Applications in browsers that support CORS can therefore now successfully make calls to an OpenAM server that runs in a different domain from the application.Instead, you must configure CORS support in OpenAM’s deployment descriptor. For instructions, see the Installation Guide section Enabling CORS Support.
  • Session Failover Across SitesOpenAM now allows session failover across OpenAM Sites. In order to take advantage of this capability, you must make sure that the underlying Core Token Service (CTS) replicates session data across your OpenAM Sites.For details on setting up the underlying Core Token Service, see the Installation Guide chapter Configuring the Core Token Service.
  • Reduced Cross-TalkOpenAM now attempts to locate a user’s session in the Core Token Service (CTS) store before making a crosstalk request through a back channel to other OpenAM servers in the cluster.The reduction in network traffic can increase performance.For more information, see the Install Guide section To Configure Site Load Balancing.
  • Asynchronous Core Token Service RequestsA change to the Core Token Service (CTS) means that requests are no longer performed synchronously. CTS processes all requests asynchronously in the background, allowing callers (that is, those entities that call CTS) to send subsequent requests without waiting for a previous request to finish processing, improving response times and performance.For more information, see the Install Guide section CTS Tuning Considerations.
  • Fine-Grained Settings for LDAP ConnectionsOpenAM now provides additional options for tuning LDAP connection pool sizes and timeouts related to the Core Token Service and to other components that use LDAP connections. For more information, see the Administration Guide section Tuning LDAP CTS & Configuration Store Settings.
  • REST Policy Filter RulesOpenAM now supports REST Policy Filter rules that simplify the configuration to protect ForgeRock common REST APIs.
  • OAuth 2.0 Scope ConditionsOpenAM now supports an OAuth2 Scope condition that lets the you set required OAuth 2.0 scopes as a policy condition.
  • Configurable DN Cache for LDAP Data StoresOpenAM now has the capability to enable and disable DN caching. DN caching helps avoid DN lookups that can happen in bursts during authentication. ( OPENAM-3822 ).
  • Quicker UI CustomizationWhile customizing the UI, you can set the advanced server property, org.forgerock.openam.core.resource.lookup.cache.enabled, to false to allow OpenAM immediately to pick up changes to the files as you customize them (OPENAM-3989). You can set advanced server properties in OpenAM Console under Configuration > Servers and Sites > Server Name > Advanced. For production servers, leave this set to the default, true.
  • Whitelist for Custom Login URIsOpenAM now includes a property that specifies a whitelist for custom login URIs so that the CDCServlet and the Distributed Authentication UI (DAS) can check login URI values against those in the whitelist.The property name is org.forgerock.openam.cdc.validLoginURIs. For more information about this property, see the Reference section on advanced properties, Servers > Advanced.
  • OpenID Connect Registration Without an Access TokenOpenAM can now be configured to let OpenID Connect clients register dynamically without having to provide an access token (OPENAM-3604). For details, see the documentation on the advanced server property, org.forgerock.openam.openidconnect.allow.open.dynamic.registration, in the OpenAM Reference section, Servers > Advanced.
  • Policy Support for Common HTTP OperationsOpenAM policies now let you allow and deny not only HTTP GET and HTTP POST, but also HTTP DELETE, HEAD, OPTIONS, PATCH, and PUT (OPENAM-336).

  • REST Logging

    OpenAM now supports audit logging and debug notifications for any request going to a common REST (CREST) endpoint. OpenAM audits every request going to any CREST endpoint and writes to two files: amRest.access and amRest.authx.

    The amRest.access file records all accesses to a CREST endpoint (except /authenticate), regardless of whether the request successfully reached the endpoint through policy authorization.

    The amRest.authz file records all CREST authorization results regardless of success. If a request has an entry in the amRest.access log, but no corresponding entry in amRest.authz, then that endpoint was not protected by an authorization filter and therefore the request was granted access to the resource.

    OpenAM now provides additional information in its debug notifications depending on the message type (error, warning or message) including realm, user, and result of the operation.

    For more information on CREST logging, see Logging.

janua
Les derniers articles par janua (tout voir)