What are the best practices to restrict access to specific authentication journeys (trees) and ensure that only authorized users or systems can invoke them? Are there any built-in features in ForgeRock AM to achieve this, or do I need to implement additional measures like API gateway restrictions or IP whitelisting?
Hi Karan
There are different types of checks you can do depending on the use-case for the journey.
For e.g., you could check:
a. If the user is a member or admin of a specific org
b. If the user is a member of a group
c. If the user is a member of an internal role
d. If the user is assigned to an app
e. If the user is assigned to a specific role
f. If a certain attribute in user’s profile is set to a certain value
Example use-case: You created a journey for helpdesk users and exposed it as a bookmark app AND you want to ensure that only helpdesk users can access it.
In this case, you could create a role and assign it to your helpdesk users. When the journey is launched, you could get user’s id and check if the user is assigned that role. If yes, user can continue. If not, you could throw an error - “You are not authorized…”.
If your journey is being invoked by an external system, you could look at generating and sharing a strong secret and require the calling system to provide the secret as a header when calling the journey. If the secret is not provided or is incorrect, you could fail the journey.
I like the question.
As you can see, the answer to a related question is to ensure the correct verifications for the identity are included in the Auth-N tree, itself.
As such, the invocation has occurred.
As opposed to “restrict”, let’s use “mitigate the effects of the unauthorized…”.
If we think along these terms, there are a few good practices we could follow (and ignoring filtering techniques external to AM):
- Using Inner/outer tree methodology. Allowing the outer tree to perform the early filtering of “the authorized”.
- Using jwt based Authentication sessions. (Stateless, or client based, if you will)
- And including some form of early client detection/validating a client profile or perhaps a persistent cookie check. (Circling back to 1.)
Etcetera, etcetera.
Of course, if you are not careful, the resulting authentication journey could be quite daunting …. As many have succeeded in doing.
“Ensure that only authorized users” can access a journey: this is bit like asking who is first, the chicken or the egg? I mean, how can you authorise a user to enter a journey before authentication, when you don’t know yet the user, only after authentication?
As for systems access, perhaps this one belongs to an edge component, such as Identity Gateway, perhaps using client certificates?
And if you meant authenticating, then authorising in the journey, then my motto is: don’t mix those two concerns. The journey ensure the user is rightfully authenticated. The session token is then the passport that gives access to other things - obtaining an access token with allowed scopes, an id token with carefully crafted claims, or even a session properly minted with the user’s access rights, or simply using AM’s Authz policy engine. Let another component take care for the authorisation enforcement, aka the PEP.
1 Like
@grpensa @patrick_diligent Thanks for your reply. Just a follow up question.
How can we ensure that only authorized clients or systems can invoke an authentication journey in ForgeRock Identity Cloud?
Specifically, we want to prevent unauthorized or malicious clients from even initiating the journey, or ensure that if they do invoke it, some validation mechanism (like a client certificate or identity gateway) is in place to block them. Once the journey is invoked, how do we separate the concern of authorization so that it doesn’t interfere with the authentication flow? Can we use components like Identity Gateway or token-based mechanisms (JWT, access tokens) to handle these security layers effectively?
Yes, basically adding some proof in the payload is the way to go. This not authorisation at the user level, but at the application level. So just end the journey in Login failure for an invalid access.