Common P1AIC mistakes

PingOne Advanced Identity Cloud (P1AIC, for short) provides the most powerful identity management software (yes, I work for Ping, and I am biased. Prove me wrong) as a convenient software-as-a-service. Customers can depend on Ping to run and maintain the platform for them, and a lot of the worries of using self managed software are taken care of. Yet the P1AIC gives the customer a lot of freedom with endless extension points and its incredibly powerful authentication journeys. And as with all great freedom, there is the possibility of getting things wrong.

I’ve worked with dozens of customers helping them implement P1AIC. Below are 5 common mistakes I see them make. They are in no particular order and are not necessarily the worst mistakes that can be made, but they are common pitfalls worth keeping in mind.

1. Not setting user attribute rights

The alpha_ and bravo_user managed objects have a range of settings that determine the privileges a logged-in user has over their own properties. The enduser UI can be used to keep a user’s own profile up to date. Depending on the use case, that functionality is great for properties like the first and last name. But all too often, these privileges are not correctly set for properties that should not be changeable, such as those that influence the journey decision logic.

As a best practice, enforce the principle of least privilege by removing all permissions on all properties, then enabling them only for those with a clear business need for self-service.

2. Not using the appropriate journey flags

Recent updates to P1AIC introduced support for a range of flags that can be set on the journey to influence its overall behaviour. When updating existing journeys or creating new ones, review those flags and set them appropriately.

Enforce inner journey

The flag innerTreeOnly ensures the journey can only be used as an inner journey. This ensures that the journey cannot be called directly using the serviceAuthIndex URL parameter and potentially enable a malicious user to circumvent authentication policies.

No session

Journeys can be used not only for authentication, but also as a workflow for identity management. Examples could be password reset or registration journeys. Often, these journeys should not lead to a new session for the user after completion. If a journey has the noSession flag enabled, no session will be created.

mustRun

The default behaviour of journeys is to execute only if the user doesn’t already have an established session. A caller can add the ForceAuth=true URL parameter to the request to force a session upgrade, but a malicious user can remove it. For scenarios where the journey must run to completion each time, the mustRun property can be set. This forces a session upgrade that the user cannot circumvent.

A use case for this could be to re-run an MFA or risk evaluation. To make sure the user doesn’t have to re-authenticate from scratch each time - having to provide username and password, for example - the journey can check for an existing session using a custom or scripted decision node and only enforce the part of the journey that is required for re-authentication.

session durations

Session timeouts can be set on a per journey level. This applies to both the authentication and login sessions. Extending the authentication session duration can be helpful in progressive profiling use cases. For example, a journey can allow more time when the user must provide additional data that may not be immediately accessible, such as a passport number.

The timeouts can also be set within the journey using the Update Journey Timeout node or through scripted decision nodes. The email suspend node has an optional parameter to set the suspend duration, to ensure the user has enough time to find the email.

3. Not following general development best practices

P1AIC’s flexibility is driven mainly by the many scriptable extension points it offers. Authentication journeys can be seen as individual programs. As with other software development efforts, companies should integrate their P1AIC deployment into a software development lifecycle (SDLC). Policies such as coding standards, automated testing and code management should be enforced and aligned with the company’s overall SDLC. The following are some specific points to consider.

Copy and pasting code

Duplicating code is never a great idea; the same goes for scripted decision nodes. It makes code hard to read. Updating the common code means updating every instance where the copied code is used. Instead, move common functionality out into library scripts and enforce a standard build.

Not tracking and resolving technical debt

In complex setups, workarounds, quick fixes and shortcuts will inevitably find their way into a deployment. As much as we strive to avoid them, the reality is that deadlines must be met, requirements are evolving, and P1AIC is introducing new features that make some of our efforts redundant. It is therefore essential to track technical debt and make refactoring a part of normal operations.

Overcomplicating journeys

Authentication journeys are great; you can do pretty much any identity workflow you can imagine. But should you? The goal of an authentication journey should be to execute as fast as possible and to be easy to maintain. When journeys start to have dozens of branches and multiple layers of inner journeys, it becomes increasingly harder to understand and maintain it. Performance drops, and customers abandon the login process and go elsewhere. Sticking to the ‘Keep it Simple’ principle is the way to go.

4. No configuration management

Configuration management encompasses everything from how configuration is applied to a tenant, how it is reviewed and tested and how it is promoted to the production environment. Without those processes and tools in place, it is all too easy to promote unwanted changes or inadvertently open security holes. This is a big topic, I’ve written blogs (part1 and part2) describing configuration management and contributed to tools (fr-config-manager) that support the process. Note the above links reference ForgeRock Identity Cloud. Since Ping merged with ForgeRock, the name of ForgeRock Idnetity Cloud has changed to PingOne Advanced Identity Cloud, but the functionality is the same.

The earlier in the project configuration management is implemented, the easier it is to do. Retrofitting after going live is often painful and can delay further development.

5. Using openidm bindings for everything

OpenIDM binding (openidm.query, openidm.patch, etc) in scripted decision nodes can enable powerful workflows using journeys. They make finding or updating a user trivial. Combined with custom managed objects, they can provide a convenient way to make arbitrary data available to a journey. But all that flexibility comes at the cost of performance. The openidm binding uses HTTP calls to the IDM side of P1AIC, which causes some overhead and slower performance. This can be problematic for login journeys, which are called at high frequency, and the user expects swift response times.

So when designing custom nodes or scripted decision nodes, instead of using the openidm binding, consider using the idRepository binding instead. idRepository.getAttributeValues does direct LDAP calls using pooled connections and is therefore blazingly fast. However, when using idRepository.setAttribute to update an attribute, IDM will not be notified. If IDM is configured to trigger an action based on that attribute change, the update will not trigger that action. So as a best practice, use idRepository for fast reads, and if using idRepository for attribute updates, document this feature and consider putting a description in that attribute so it is clear the attribute cannot be used as a trigger for IDM actions.