How to access request url in scripted decision Node?

Integrations
, , , , ,
#1

How can we access the request url in a scripted decision node? According to below backstage doc

https://backstage.forgerock.com/docs/idcloud/latest/am-authentication/scripting-api-node.html

we only have access to requestHeaders and requestParameters.

#2

Is the “request URL” the original URL the user intended to access? If yes, it depends what federation protocol is being used. For example, if you are using OIDC, the “request URL” can be passed as a state parameter, and then you can access it via requestParameters in your scripted decision node. And if you are using the SAML2 federation protocol, the original “request URL” can be persisted into relaystate, and access it via requestParameters in your scripted decision node.

#3

@jsingh User is going to access the authentication journey url. Scripted decision node api does not have any methods to access same.

#4

How does a user get to the authentication journey URL? Could you please share your use case?

#5

@jsingh We want to protect the auth. journey being accessible from production tenant. Ways via which we can do so for different protocol like OIDC and SAML is one of the ways. But how can we achieve this if end users/ bad actor try to access the journey url directly?

#6

Be careful not to divert from the original state intent in the OAuth2 protocol, as specified by RFC 6819: OAuth 2.0 Threat Model and Security Considerations


3.6.  "state" Parameter

   The "state" parameter is used to link requests and callbacks to
   prevent cross-site request forgery attacks (see Section 4.4.1.8)
   where an attacker authorizes access to his own resources and then
   tricks a user into following a redirect with the attacker's token.
   This parameter should bind to the authenticated state in a user agent
   and, as per the core OAuth spec, the user agent must be capable of
   keeping it in a location accessible only by the client and user
   agent, i.e., protected by same-origin policy.

With regards to prevent direct access to some journeys, in a self-managed deployment this can be easily achieved with an edge component such as Identity Gateway, where everything is funnelled to that layer. Unfortunately this model is not available in ForgeTock Identity Cloud - accesses are all public. You’re not the first to comment on this - and you could submit a ticket to ForgeRock support to add your voice in that matter.
In the meantime, a workaround would consist in setting an entry check to the journey - such as a short lived signed JWT in a header that validates the requester, or some certified value in shared state when calling an inner journey.

Regards
Patrick

1 Like
#7

Gotcha! In that scenario, it’s crucial to ascertain the authenticity of a request from the outset. One effective way to achieve this is by verifying a signed value received from the Client or SP at the beginning of your journey, as Patrick mentioned. And if authenticity check is not a requirement, an IP address-based validation (via ESVs) can also be performed at the Journey level before kicking-off the modality.