IBM Security Verify

 View Only
Expand all | Collapse all

InfoMap - retrieve original requested URL

  • 1.  InfoMap - retrieve original requested URL

    Posted Thu August 15, 2019 09:27 AM

    Hello,

     

                    I am using ISAM 9.0.7.0 can trying to leverage the AAC component and InfoMap.

    I'm trying to retrieve the original requested URL from the JavaScript in the InfoMap.  I was hoping to be able to get it in either the request or session context via

    var dest = context.get(Scope.SESSION, Attribute Namespace, Attribute ID);

    var dest = context.get(Scope.REQUEST, Attribute Namespace, Attribute ID);

     

    Is there an Attribute Namespace and Attribute ID that I can use to get the original requested URL?  Or is there another of retrieving the URL? 

    Within the Infomap the "dest" variable will be a URL parameter for another URL.  The original URL(dest) will vary so I can't use a static URL.

     

    The flow is

    1. User requested protected content /junction/context/originalURL.html
      1. An access policy is attached to /junction/context/originalURL.html
    2. Webseal prompts for authentication
    3. User authenticates and the access policy is triggered
    4. Infomap will send to request to Servlet with the dest as a URL parameter
    5. Servlet will initiate a few redirects back in forth passing the dest as a URL parameter
    6. Once servlet has gathered all needed info it will request to send to the "dest" URL
    7. Request will go to "dest" URL and the access policy will be respond with Permit and be allowed.

     

    Is this doable?

     

    Thanks,

    Duane



    ------------------------------
    Duane Morrison
    ------------------------------


  • 2.  RE: InfoMap - retrieve original requested URL

    Posted Wed August 21, 2019 03:41 AM
    You should not need to do this. WebSEAL will cache the originally requested URL of the protected content and as soon as your EAI application (whether it be AAC/InfoMap or your own servlet) returns the EAI headers to allow WebSEAL to authenticate, it will direct the user's browser to the originally requested URL. Until that EAI response containing the authentication headers happens, as many "unauthenticated" exchanges back and forth between the browser and backend URLs can occur on the same session without any problems.

    Further, it's generally a bad idea to pass URLs to redirect to around as parameters. This normally ends up forming an anti-pattern known as an Open Redirector (google it if unfamiliar) which hackers love because it will make a request to a malicious URL look like it came from your ISAM deployment.

    ------------------------------
    Shane Weeden
    IBM
    ------------------------------

    Original Message