can openam keep the hash value in url when redirect to SP after authentication

This topic has 4 replies, 4 voices, and was last updated 6 years, 3 months ago by Peter Major.

  • Author
    Posts
  • #6374
     xualu
    Participant

    Hi Openam experts, just as described in the subject, suppose user want to access a url with a hash value like http://sp.example.com/someurl/#somehashvalue, then openam web agent redirect to openam authentication server to do authentication, after authentication process, user will be redirect back to the service provider. At this time, the hash value #somehashvalue has been wiped out after redirect. So is there any way to keep this hash value?

    #6383
     ssripathy
    Participant

    What’s the hashed value for? Is that a deep link to the target? Have you tried to trace it using firebug to see what the RelayState value looks like. Could it not be the SP wiping it out and not OpenAM IDP?

    #6391
     xualu
    Participant

    Thank you ssripathy for your answer. The hashed value is for javascript to do further process. It should not be wiped out by the SP because before I using openam for SSO, the hash value works fine. But when using openam for SSO, the hash value is lost in the “goto” parameter when redirect to openam login page.

    #11700
     praveen.iips
    Participant

    Hi xualu.. Did you find solution to keep persist hash value in url?

    #11704
     Peter Major
    Moderator

    Looks like there is some confusion here. The SP term is being used (which is SAML terminology), yet there is an agent is involved as well (which is not implementing SAML).
    The fragment part of the URL is *never* sent to the actual server that deals with unauthorized requests, simply put, the agent never sees the fragment value on the incoming request, so it of course won’t be available in the goto parameter.
    The actual fragment itself will be carried over to the login page though (so if you check the URL after the redirect you should see the fragment appended to the login request (as the fragment for that page, and not as part of the goto parameter). If you want to keep the fragment in the goto, then you should probably customize the login page to somehow amend the goto parameter’s value on the client side.

    See also OPENAM-2164.

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.

©2022 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?