Forgerock OpenDJ

OpenDJ is a directory service that is compliant with LDAPv3 requirements. It is developed for Java and Windows platform and provides a high level of access and performance, and secure storage for the identities on your organization’s system.

It is straightforward to install, and combined with the robust capabilities of the Java platform, Forgerock OpenDJ is the quickest and simplest directory for any organization to manage and deploy identities.

It is an open source, embeddable, and lightweight directory that can quickly send device, customer, and user identity in real-time across the enterprise, social, cloud, and mobile environments. You can expect:

  • Robust data scale and advanced availability that provides developers with lightweight options to access identity data
  • High performance regarding response times at a rate of ten thousand of w/r every second
  • Multi-Master duplication for fast turnaround

In addition to LDAP access, Forgerock OpenDJ allows you to access directory data via HTTP as JSON resources which I every convenient for phone and web apps. The software provides users with unrivaled flexibility regarding customization of user IAM experience.

OpenDJ allows you to neglect inflexible GUIs thus allowing implementers an avenue to deliver the feature a and functionality needed to satisfy solution guidelines.

The solution requirements include the implementation and design of a highly available and performant, and scalable digital identity vendor that allows users to:

  • Open accounts
  • Update credentials and general profile
  • Use their account as a centralized point for identity federation
  • Connect with other services

We are here for you

Allow us to help you pick the best of bread solution for your IAM Issues

Security Considerations for Forgerock OpenDJ

Authentication and Session Management

Forgerock OpenAm interface requires users to deliver their credentials as URL parameters for every access attempt made to the backend. To avoid a mix-up of credentials, the given infrastructure allows the browser to don’t users proof of identification as an SSL-encrypted cookie and use this advantage to work on the middle-tier server to identify credentials from. The token and change the browser request to the usual OpenIDM REST call.

Authorization and Anti-Framing

It can be challenging to differentiate real clients from fake ones when anonymous device requests are involved as they do not provide user credentials. OWASP guidelines suggest CAPTCHA and client-side SSL in such cases.

At GCA, and with Identity Access Management, client-side SSL is not applicable. The solution adopts CAPTCHA verification in such scenarios. An advanced layer of security further supports this via the load balancing appliances.

Protecting HTTP Actions and Methods

OpenAM interface provides access to backend entities via HTTP actions and methods. There is an additional role-based access control function to protect resources against unauthenticated access.

This service is used to create an access whitelist by mirroring the minimum privilege principle. Additionally, for the majority of the endpoint URLs, only REST calls are allowed to reach the middle-tier server based on its involvement in the designed infrastructure.

In many cases, the same action can be executed via different REST endpoints. While some are resource-based (using HTTP verbs with resources defined in the path), others are general-based utilizing only POST, which gives the resource aces to the JSON payload.

In many cases, the use of generalized POSTs is avoided which allows for additional ambiguity and can theoretically be used to trigger unintended actions.

Output Encoding and Input Validation

Cauterizing input and output data that streams into and out of the IAM stack are one of the essential security requirements that any capable IAM Solution should execute. Failure to validate input data is liable to leakage and tampering of the system’s internal architecture, and lack of output data can cause sensitive information to be accessed by an unverified user.

Thankfully, Forgerock OpenDJ provides OOTB mechanisms that inspect input and output data to ensure they are secure. Hence, the only task your IT department is saddled with is business-level requirements of User data verification which is achieved via middle-aged JSON libraries, during signup.

Protecting against CSRF, Injection, and XSS attacks

Protection against injection and XSS attacks depends on applying input verification and the necessary privileges principle, which we discussed above. However, CSRF attack risk needs to be tackled with a different approach. The attack makes a victim browser to share a hostile HTTP request to the server.

The attack succeeds if:

  • The browser is operating on a verified session
  • The hostile HTTP request mirrors a REST call

Hence, to eliminate the risk, Forgerock OpenDJ:

  • Uses short-term session cookies
  • Use flexible GUIDs for managed user endpoints

These two features drastically reduce the risk of a CSRF attack without limiting the quality of system performance.