Our main use case for ForgeRock is to manage secure user authentication and authorization for our enterprise platform. For example, we use ForgeRock to implement OAuth 2.0 authentication flows and ensure that only authorized users can access sensitive onboarding workflows and data. A specific scenario would be when a new user is onboarded. ForgeRock handles the authentication process, enforces multi-factor authentication, and manages user roles and permissions to control access to different stages of the onboarding lifecycle, such as draft, submission, approval, and finalization. This integration helps us maintain regulatory compliance as well as auditability and security with multiple user roles, while also streamlining user experience and reducing the risk of unauthorized access.

Integrating ForgeRock with our onboarding workflows has been a valuable learning experience because there are both smooth and challenging aspects. The smoothest part is ForgeRock's standards-based support for Auth and SAML, which makes it straightforward to set up secure authentication and single sign-on for our onboarding module. ForgeRock's comprehensive documentation and RESTful APIs also help accelerate the integration. One challenge is mapping our complex multi-stage onboarding workflows, where users transition between draft, submission, and approval stages to ForgeRock's role-based access controls and policy configurations. We had to carefully design custom policies and attribute mappings to ensure that only the right users could perform specific actions at each stage, which required close collaboration between our development and security teams. Another tricky aspect is handling legacy user data and ensuring seamless migration to ForgeRock without disrupting existing user access or compliance requirements. Overall, the integration is successful, and the flexibility of ForgeRock's platform allows us to tailor the solution to our specific needs.

One thing that stands out about our main use case and the integration process is how ForgeRock's centralized policy management makes it much easier to enforce consistent security and compliance rules across all stages of the onboarding process. We are able to implement fine-grained access control, so permissions can dynamically adjust based on user roles and the current status of the onboarding request. ForgeRock's auditing and versioning features are particularly valuable for our compliance needs, allowing us to track every access and every modification event. Additionally, the flexibility to integrate with our existing tech stack including Java, Spring Boot, and Apache Kafka helps us avoid major architectural changes and keeps the project timeline on track. ForgeRock's extensibility and strong support for enterprise standards are key factors in the success of our implementation.

In 2014, we had two use cases with ForgeRock. One was for consumers, with 60 million consumers of the TomTom navigation system. The other was approximately half a million use cases for B2B purposes for implementing ForgeRock in cars, with the first batch of cars being Korean vehicles.

For the consumer use case, we launched a program called One TomTom ID where a single user ID could be used to log into the web, app, and navigation device with ForgeRock. Previously, there were three different user IDs because of how the company had grown with different platforms. This was a main use case for better customer experience and improved security. For the B2B use case, different car companies wanted to get traffic information into their dashboards, and the best way to authenticate was to embed custom code into their dashboard. Whenever the car started up, the car's VIN number would be authorized if it was on the list to receive traffic information from TomTom, and they would receive it.

When authenticating a car to determine whether it was authorized to receive traffic information with ForgeRock, it was not straightforward because anyone could drive a car, so it could not be user-based. Authentication had to be based on the car's navigation ID, the dashboard ID, and the VIN number, which are directly related to the car and apply to whoever is driving it. To accomplish this, we had to issue a token. Every time a car started up for the first time and connected with the back-end system, it was issued a token that would authorize it to receive traffic information, which was a very efficient and neutral solution.

I integrated ForgeRock SSO with a web application that had React for the front end and a Spring Boot back-end API, where ForgeRock AM was acting as an authorization server and an identity provider. Users were stored in ForgeRock and LDAP through ForgeRock Directory Studio. Our goal was to enable SSO using OpenID Connect, issue JWT access tokens, and enforce MFA for sensitive actions.

We created an OIDC client and set up the client ID, redirect URI, and grant type as an authorization code. We checked all the token endpoints, defined the scopes, token lifetime, and signing algorithms. We implemented the login flow where the user goes to the app and is redirected directly to ForgeRock when the app sees no session. When ForgeRock executed the authentication tree, it handled username, password, device check, risk calculation, and optional MFA. After successful authentication, ForgeRock redirects back with the authorization code.

We also used a Spring Boot API which validates API protection and validates the JWT signature using the ForgeRock public key, checks expiration, issuer, audience, and scopes. This is how we implemented MFA and SSO.

I am using ForgeRock for standard support, policy configurations, and documentation clarity.

The pricing, setup cost, and licensing are very straightforward, which is a good success. I appreciate that it is very straightforward and helpful.

The customer support is very flexible and supportive, particularly in the area of automation and customer deployments. It is very helpful and supportive to our customers.

The main use case for ForgeRock is to work with IAM for authentication and authorization trainings, using the environments during the training sessions and providing samples for ForgeRock customers. I have trained both enterprise organizations and smaller companies. Enterprise organizations are checking if they really need to upgrade to the new version or release, while smaller companies are trying to determine if they need to start using ForgeRock.

My main use case for ForgeRock is designing user journeys, specifically customer user journeys, and how they interact with the system.

A specific example of a user journey I designed using ForgeRock is when we migrated from an older IAM system, Okta, to ForgeRock. We designed a journey to log into one of the partner portals, where the password was still authenticated via Okta for the first-time migration users. We configured pass-through authentication, and once the user's login is completed, we mark it as a migrated user, synchronizing their password with ForgeRock Directory Server. In that journey, we implemented various configurations such as step-up control and orchestration, where based on the risk level populated via PingProtect service, either a step-up is required via email or via a one-time text message before granting access.

In addition to my main use case, we have multiple use cases, with over 30 journeys live for the different systems that the company uses, including various flows such as forgot password, reset password, and forgot username, which utilize utility journeys that are repetitive in nature.

My main use case for ForgeRock includes user provisioning, deprovisioning, reconciliation, workflows, cross-federated SSO, integrating applications, third-party applications into ForgeRock, managing users and entities, and handling password resets, among other functionalities.

I onboard applications into IDM for user provisioning and SSO, managing user identities effectively. We also integrate and onboard those applications into ForgeRock Access Management, allowing users to log in to their applications, get their identities authenticated against ForgeRock, and access their applications seamlessly. This approach is especially pertinent as we focus on customer IAM, utilizing CIAM profiles.

My main use case for ForgeRock is mostly access management related fine-grained access management for customer identities.

For fine-grained access management, I use ForgeRock based on the customer base, whether they belong to a particular company or a particular third party. I consider what their use cases are and how they want to integrate or access the applications. Accordingly, I expose ForgeRock Access Management integration either via OAuth 2 or SAML 2 integration, allowing them to access the application in a secure way.

My customers also want to include the multi-factor authentication component, using mobile verification or email verification. They want to store their profile details so that every time they log in, they won't be prompted for MFA. It will be remembered for at least the next 30 days, and they won't be prompted for any second factor, allowing them to log in seamlessly.

I use the solution in my company for all of our authentications, specifically microservice authentications.

We use ForgeRock for access management. We access ForgeRock over VMs, but it is technically deployed on-premises.

In AUS, there is an accredited open banking solution. We worked on a security profile using ForgeRock. We used four or five ForgeRock components, including Access Management, Identity Gateway, Identity Management, and Directory Stores. Another use case is the insurance side, but it's also consumer identity and Access management.

When I'm working on the client's site, it's a different user base, so I'm not sure how many people or products there are. I think both organizations are using ForgeRock to manage that data for many projects.

We use ForgeRock for providing application security.

If for example, you click on facebook.com, the request goes from your browser to the application server. On the application server, one of the gateways may block your request. First it enters the firewall and then it reaches the application server where Facebook is deployed and it reaches a policy enforcement point. This policy enforcement point (PEP) would be the web agent.

This request is blocked by this PEP, and it asks the basic first question of whether the URL is protected. The user then provides their credentials on their login screen and again, this PEP takes up this request to PDP and asks whether this user is authenticated to access this service. The credentials are checked in a user store. 

So as soon as it checks your credentials, it gives back an answer to the policy decision point that this user is available in the user store. ForgeRock answers all these questions using its own codes.

We mainly use the solution for profile management authorization, and authentication as well as data migration. 

We use it for our enterprise workforce as well as for customer identity and access management. Our enterprise workforce is around 60,000 users and our customer base is approximately 100 million users.

We use ForgeRock to implement SSO MSA for different customers with large databases. We also use the solution to unify their system and dashboards.

We are using ForgeRock for our CRM system.

ForgeRock is basically an IAM tool and we use it for access to multiple resources or applications. It's basically an identity and access management tool. We are business partners with ForgeRock and I'm a security delivery analyst.

We primarily use the solution for multiple clients and multiple implementations.

One of my company's customers has already integrated ForgeRock and set up Splunk. We just did some simple configuration, but not much since our customer did it.

I use the tool for its single sign-on capabilities. With ForgeRock, we can enable single sign-on and multi-factor authentication features, as well as single-layer or two-layer multi-factor authentication and password-less authentication.

There are multiple use cases including multi-factor authentication that enable more integration on the application stack. There's also the CIAM methodology with the single sign-on, the SAML integration and the federation for business to business. We are partners with ForgeRock and I'm an SME. 

We are using off protocol to protect the application for multiple redirects and single redirects. We have multiple flows and from there an authentication perspective. We do have IDM in place to manage roles and also provisioning activities.

We use the solution for the authorization and authentication of various applications.

My clients use the solution primarily for customer identity management, access management, customer onboarding, data management, and authentication.

We use this solution to manage the identity and access of users to SI and other applications of our company. We implement the identity of the users in that SI.

I have been using ForgeRock as a central repository for identities. We have OpenIDM as one of the products. We also have access management and single sign-on authentication for single sign-on purposes. 

There are different use cases. One of the interesting projects was to use ForgeRock as software as a service for the biggest telecommunication company in Switzerland. They used it as a service for their customers.

We use this product as an access management platform.

We use it to define the users in all of our systems like VMS and Samba. We don't use Windows, we use Samba. We create and define the permissions and configurations for the users. 

The primary use of this solution is as an access management system.

The solution is primarily used for the consumers, for their registration and other applications.

We are consultants who have deployed versions of the ForgeRock solution.