Can't get profile attributes in HTTP headers

This topic has 9 replies, 5 voices, and was last updated 5 years, 5 months ago by Peter Major.

  • Author
    Posts
  • #6742
     nhirsl
    Participant

    Hi,

    Can you, please, help me in setting up config and agents so profile attributes are passed to the client? I can’t get these attributes in headers.

    Let me summarize and describe current environment:
    1. Openam (13 nightly) installed on openam.domain1.com
    2. Opendj installed on opendj.domain1.com
    3. Configured so the users can be successfully managed
    4. Application running on app.domain1.com is guarded by web agent (apache 2.4 linux 64bit – 20151027)
    5. Application running on app.domain2.com is guard by web agent which is configured for cdsso
    6. Cookie domains are set up
    7. Policy created to guard http://app.domain1.com:80/* and http://app.domain2.com:80/*.
    8. Response attributes selected in the policy (uid, mail, givenName)
    9. SSO tested on both applications (.domain1 and .domain2) and working. After user is successfully authenticated and authorized, it can access apps on both domains. Agent audit logs prove that.
    10. However, there are no HTTP headers with configured data:
    Profile attributes fetch mode set to HTTP headers
    Profile attribute map has: [uid]=MY-uid, [mail]=MY-mail, [givenName]=My-given-name

    It seems that agent has all data it needs:
    2016-01-10 14:52:03.520 +0100 DEBUG [0x7fc8b7c2b840:7926][source/process.c:1442] do_header_set(): clearing MY-mail
    2016-01-10 14:52:03.520 +0100 DEBUG [0x7fc8b7c2b840:7926][source/process.c:1442] do_header_set(): clearing MY-given-name
    2016-01-10 14:52:03.520 +0100 DEBUG [0x7fc8b7c2b840:7926][source/process.c:1442] do_header_set(): clearing MY-uid
    2016-01-10 14:52:03.520 +0100 DEBUG [0x7fc8b7c2b840:7926][source/process.c:1438] do_header_set(): setting MY-mail: [email protected]
    2016-01-10 14:52:03.520 +0100 DEBUG [0x7fc8b7c2b840:7926][source/process.c:1438] do_header_set(): setting MY-given-name: Name
    2016-01-10 14:52:03.520 +0100 DEBUG [0x7fc8b7c2b840:7926][source/process.c:1438] do_header_set(): setting MY-uid: myuser_tmp
    But when I look up for these headers in chrome dev tools, they are missing – no trace of such or similar data in existing headers.

    Interesting fact is that if I change fetch mode to cookie, it works ok. Cookie is created and I can see the data.

    Unfortunately, this workaround (using cookies instead of http headers) is not working on agent configured for cdsso. I’ll post more details when I collect debug logs and investigate what might be the problem there.

    Thanks in advance!

    Regards,
    Nemanja

    #6747
     Scott Heger
    Participant

    How are you trying to view the headers? Keep in mind that they won’t be visible to the user’s browser as the agent injects them just before allowing the request to pass to your application. You would need code in your app to expose the headers that are in the request.

    #6748
     Rogerio Rondini
    Participant

    Hi Nemanja,

    I`m not sure but maybe the problem is the use of “-” in the name of attribute.

    Try to do [uid]=MYuid instead of [uid]=MY-uid.

    Abs.

    #6749
     Scott Heger
    Participant

    Ah, I see that you are trying to view them in Chrome via the developer tools. As stated in my previous post, you won’t see them there. Add some code in your app to display them.

    #6752
     Rogerio Rondini
    Participant

    Yes.. need a code to get from header, not by the Chrome tool.

    #6771
     nhirsl
    Participant

    Thanks for prompt responses.

    Should this be server side app to read headers? Is it possible to read them on client side – java script, so the client can use these data?

    As for agent on cdsso and profile attributes:
    Both agents: one on the same domain as openam, the other on different domain are configured pretty much the same. The only difference is that cdsso is enabled on later and appropriate domains are set for cookies.
    As stated in first post, SSO is working properly, but in this case, on cdsso agent, I don’t get profile attributes at all – not in headers, nor in cookies.

    Log looks ok, till the last line: “all set user attribute options are set to none”
    On agent1, this is the place where profile attributes are set.

    2016-01-12 14:34:08.713 +0100 DEBUG [0x7fbd3624a840:16338][source/process.c:1198] validate_policy(): method: GET, decision: allow
    2016-01-12 14:34:08.713 +0100 DEBUG [0x7fbd3624a840:16338][source/process.c:1707] handle_exit(): (entry status: success)
    2016-01-12 14:34:08.713 +0100 DEBUG [0x7fbd3624a840:16338][source/apache/agent.c:267] set_user(): username_tmp
    2016-01-12 14:34:08.713 +0100 DEBUG [0x7fbd3624a840:16338][source/process.c:1499] set_user_attributes(): setting session cookie in .domain1.com domain
    2016-01-12 14:34:08.713 +0100 DEBUG [0x7fbd3624a840:16338][source/process.c:1375] do_cookie_set_generic(): iPlanetDirectoryPro=AQIC5wM2LY4SfcyT9M5I8eO_R6RWot0c2DeZ4tOxJj-OyR4.*AAJTSQACMDEAAlNLABQtMjgyNDkwMzAzODgzNDE4MDI2MQACUzEAAA..*;Max-Age=300;Expires=Tue, 12-Jan-2016 13:39:08 GMT;Domain=.domain1.com;Path=/
    2016-01-12 14:34:08.713 +0100 DEBUG [0x7fbd3624a840:16338][source/process.c:1499] set_user_attributes(): setting session cookie in .domain2.com domain
    2016-01-12 14:34:08.713 +0100 DEBUG [0x7fbd3624a840:16338][source/process.c:1375] do_cookie_set_generic(): iPlanetDirectoryPro=AQIC5wM2LY4SfcyT9M5I8eO_R6RWot0c2DeZ4tOxJj-OyR4.*AAJTSQACMDEAAlNLABQtMjgyNDkwMzAzODgzNDE4MDI2MQACUzEAAA..*;Max-Age=300;Expires=Tue, 12-Jan-2016 13:39:08 GMT;Domain=.domain2.com;Path=/
    2016-01-12 14:34:08.713 +0100 DEBUG [0x7fbd3624a840:16338][source/process.c:1513] set_user_attributes(): all set user attribute options are set to none

    No matter how profile attributes fetch mode are set: to HTTP headers or cookies, the outcome is the same.

    #6774
     Scott Heger
    Participant

    By way of the agent alone it is not possible to make those headers available client side. They are injected after the client sends the request into the agent. You would need to do something on the app side to make them available to the client.

    As for the headers or cookies in the cdsso enabled agent….not sure….but I would double check your settings. Make sure you select one of the fetch modes and save the setting. To rule out an issue with notifications between your OpenAM server and your agent I would also restart the web container with the agent so you know that it reads its configuration.

    #6897
     nhirsl
    Participant

    Thanks for clarification about headers, server and client side apps.

    Regarding cdsso enabled agent: All settings were correct, and restart of the web container with the agent did the trick. Everything is OK now and headers are indeed passed to the cdsso agent.

    #16173
     aktokas
    Participant

    Hi Nemanja,
    Can you please share the javascript you used to fetch the attributes client side, if you still have them.
    I have recently started working on OpenAM and i am working on how to fetch the attributes using HTTP headers.
    Thanks in Advance.
    Akshay

    #16186
     Peter Major
    Moderator

    My response on https://forgerock.org/topic/fetching-profile-attributes-using-http-header/ could be of some help as well.

    Just to comment on the initial post:
    If you have configured resource attributes on the policy itself, then it makes no sense to configure profile attribute mapping at the same time. Instead you should use Response Attribute Mapping settings instead, since the policy evaluation result will already include the user details.
    Using Profile Attribute Mapping will retrieve the attributes again from OpenAM for no apparent reason – you already have received the attributes as part of the policy evaluation.

Viewing 10 posts - 1 through 10 (of 10 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?