Hi Team,

I am using ISVA10.0.4.0 IF1

For my usecase I need to preserve the claim_json. I decided to put it in the credential by putting it in an am-eai-xattrs header called: claim_json

I am using this line in my code in my mapping rule:
stsuu.addAttribute(new com.tivoli.am.fim.trustserver.sts.uuser.Attribute("claim_json", "urn:ibm:names:ITFIM:5.1:accessmanager", claim_json));

Now the end user gets an error:
Could not authenticate user. An EAI server returned invalid authentication data. (0x38cf081d)

After some investigation I saw that part of the data in the claim_json is encoded. The character I encountered is: eb Which is the encoding for ë.

Is it even possible to use encoded data in an am-eai-xattrs reponse header?
Or is this a bug in the proxy interpreting the header?

Regards,

Paul van den Brink

My advice is to either:

1. Perform base64urlencode(JSON.stringify(claim_json)) and store that encoded value in the credential. When it is needed later, perform the reverse decoding to get back to JSON; or 
2. Unless this data is being accessed very regularly, a better option might be to store it in IDMappingExtCache keyed off the user_session_index of the credential so that the credential is not very large since credential headers are usually sent on every request to junctioned servers, and large credentials will have a performance implication.

Hi Team,

I am using ISVA10.0.4.0 IF1

For my usecase I need to preserve the claim_json. I decided to put it in the credential by putting it in an am-eai-xattrs header called: claim_json

I am using this line in my code in my mapping rule:
stsuu.addAttribute(new com.tivoli.am.fim.trustserver.sts.uuser.Attribute("claim_json", "urn:ibm:names:ITFIM:5.1:accessmanager", claim_json));

Now the end user gets an error:
Could not authenticate user. An EAI server returned invalid authentication data. (0x38cf081d)

After some investigation I saw that part of the data in the claim_json is encoded. The character I encountered is: eb Which is the encoding for ë.

Is it even possible to use encoded data in an am-eai-xattrs reponse header?
Or is this a bug in the proxy interpreting the header?

Regards,

Paul van den Brink

Hi Shane,

Thanks for the suggestions.

For now I am going with option 1.
I am using this for the encoding:
    var claim_json_e = java.util.Base64.getUrlEncoder().encodeToString(claim_json.getBytes());
    stsuu.addAttribute(new com.tivoli.am.fim.trustserver.sts.uuser.Attribute("claim_json", "urn:ibm:names:ITFIM:5.1:accessmanager", claim_json_e));

And this for the decoding:
    var claim_json_e=context.get(Scope.REQUEST, "urn:ibm:security:asf:request:token:attribute", "claim_json");
    var claim_json = new java.lang.String(java.util.Base64.getUrlDecoder().decode(claim_json_e));

Using IDMappingExtCache is a nice option to explore but in our case the claim_json is handed to us in the oidc-rp flow, so there is no user_session_index yet to use as a key.

Thanks!

Regards,
Paul van den Brink

My advice is to either:

1. Perform base64urlencode(JSON.stringify(claim_json)) and store that encoded value in the credential. When it is needed later, perform the reverse decoding to get back to JSON; or 
2. Unless this data is being accessed very regularly, a better option might be to store it in IDMappingExtCache keyed off the user_session_index of the credential so that the credential is not very large since credential headers are usually sent on every request to junctioned servers, and large credentials will have a performance implication.

Hi Team,

I am using ISVA10.0.4.0 IF1

For my usecase I need to preserve the claim_json. I decided to put it in the credential by putting it in an am-eai-xattrs header called: claim_json

I am using this line in my code in my mapping rule:
stsuu.addAttribute(new com.tivoli.am.fim.trustserver.sts.uuser.Attribute("claim_json", "urn:ibm:names:ITFIM:5.1:accessmanager", claim_json));

Now the end user gets an error:
Could not authenticate user. An EAI server returned invalid authentication data. (0x38cf081d)

After some investigation I saw that part of the data in the claim_json is encoded. The character I encountered is: eb Which is the encoding for ë.

Is it even possible to use encoded data in an am-eai-xattrs reponse header?
Or is this a bug in the proxy interpreting the header?

Regards,

Paul van den Brink

What you have described should work fine however I do want to point out you absolutely can use option 2, even in the oidc-rp use case. Just turn on this in the WRP config file:

[session]

Hi Shane,

Thanks for the suggestions.

For now I am going with option 1.
I am using this for the encoding:
    var claim_json_e = java.util.Base64.getUrlEncoder().encodeToString(claim_json.getBytes());
    stsuu.addAttribute(new com.tivoli.am.fim.trustserver.sts.uuser.Attribute("claim_json", "urn:ibm:names:ITFIM:5.1:accessmanager", claim_json_e));

And this for the decoding:
    var claim_json_e=context.get(Scope.REQUEST, "urn:ibm:security:asf:request:token:attribute", "claim_json");
    var claim_json = new java.lang.String(java.util.Base64.getUrlDecoder().decode(claim_json_e));

Using IDMappingExtCache is a nice option to explore but in our case the claim_json is handed to us in the oidc-rp flow, so there is no user_session_index yet to use as a key.

Thanks!

Regards,
Paul van den Brink

My advice is to either:

1. Perform base64urlencode(JSON.stringify(claim_json)) and store that encoded value in the credential. When it is needed later, perform the reverse decoding to get back to JSON; or 
2. Unless this data is being accessed very regularly, a better option might be to store it in IDMappingExtCache keyed off the user_session_index of the credential so that the credential is not very large since credential headers are usually sent on every request to junctioned servers, and large credentials will have a performance implication.

Hi Team,

I am using ISVA10.0.4.0 IF1

For my usecase I need to preserve the claim_json. I decided to put it in the credential by putting it in an am-eai-xattrs header called: claim_json

I am using this line in my code in my mapping rule:
stsuu.addAttribute(new com.tivoli.am.fim.trustserver.sts.uuser.Attribute("claim_json", "urn:ibm:names:ITFIM:5.1:accessmanager", claim_json));

Now the end user gets an error:
Could not authenticate user. An EAI server returned invalid authentication data. (0x38cf081d)

After some investigation I saw that part of the data in the claim_json is encoded. The character I encountered is: eb Which is the encoding for ë.

Is it even possible to use encoded data in an am-eai-xattrs reponse header?
Or is this a bug in the proxy interpreting the header?

Regards,

Paul van den Brink

Hi Shane,

I changed the setting in the WRP config.

There is no session_index is the stsuu. Is there another setting involved here?
My mapping rule is part of a federation definition with Federation Protocol "OpenID Connect Relying Party" and Role "Relying Party".
When I try to access the session_index with:
var index = context.get(Scope.REQUEST, "urn:ibm:security:asf:request:header", "session_index");
I get:
ReferenceError: "context" is not defined.

Regards,
Paul van den Brink

What you have described should work fine however I do want to point out you absolutely can use option 2, even in the oidc-rp use case. Just turn on this in the WRP config file:

[session]

Hi Shane,

Thanks for the suggestions.

For now I am going with option 1.
I am using this for the encoding:
    var claim_json_e = java.util.Base64.getUrlEncoder().encodeToString(claim_json.getBytes());
    stsuu.addAttribute(new com.tivoli.am.fim.trustserver.sts.uuser.Attribute("claim_json", "urn:ibm:names:ITFIM:5.1:accessmanager", claim_json_e));

And this for the decoding:
    var claim_json_e=context.get(Scope.REQUEST, "urn:ibm:security:asf:request:token:attribute", "claim_json");
    var claim_json = new java.lang.String(java.util.Base64.getUrlDecoder().decode(claim_json_e));

Using IDMappingExtCache is a nice option to explore but in our case the claim_json is handed to us in the oidc-rp flow, so there is no user_session_index yet to use as a key.

Thanks!

Regards,
Paul van den Brink

My advice is to either:

1. Perform base64urlencode(JSON.stringify(claim_json)) and store that encoded value in the credential. When it is needed later, perform the reverse decoding to get back to JSON; or 
2. Unless this data is being accessed very regularly, a better option might be to store it in IDMappingExtCache keyed off the user_session_index of the credential so that the credential is not very large since credential headers are usually sent on every request to junctioned servers, and large credentials will have a performance implication.

Hi Team,

I am using ISVA10.0.4.0 IF1

For my usecase I need to preserve the claim_json. I decided to put it in the credential by putting it in an am-eai-xattrs header called: claim_json

I am using this line in my code in my mapping rule:
stsuu.addAttribute(new com.tivoli.am.fim.trustserver.sts.uuser.Attribute("claim_json", "urn:ibm:names:ITFIM:5.1:accessmanager", claim_json));

Now the end user gets an error:
Could not authenticate user. An EAI server returned invalid authentication data. (0x38cf081d)

After some investigation I saw that part of the data in the claim_json is encoded. The character I encountered is: eb Which is the encoding for ë.

Is it even possible to use encoded data in an am-eai-xattrs reponse header?
Or is this a bug in the proxy interpreting the header?

Regards,

Paul van den Brink

You're using the wrong attribute name. Configure the ivcreds app to see what is available. See: https://community.ibm.com/community/user/security/blogs/shane-weeden1/2020/12/04/rip-epacjsp-2007-2020?CommunityKey=96f617c5-4f90-4eb0-baec-2d0c4c22ab50

Hi Shane,

I changed the setting in the WRP config.

There is no session_index is the stsuu. Is there another setting involved here?
My mapping rule is part of a federation definition with Federation Protocol "OpenID Connect Relying Party" and Role "Relying Party".
When I try to access the session_index with:
var index = context.get(Scope.REQUEST, "urn:ibm:security:asf:request:header", "session_index");
I get:
ReferenceError: "context" is not defined.

Regards,
Paul van den Brink

What you have described should work fine however I do want to point out you absolutely can use option 2, even in the oidc-rp use case. Just turn on this in the WRP config file:

[session]

Hi Shane,

Thanks for the suggestions.

For now I am going with option 1.
I am using this for the encoding:
    var claim_json_e = java.util.Base64.getUrlEncoder().encodeToString(claim_json.getBytes());
    stsuu.addAttribute(new com.tivoli.am.fim.trustserver.sts.uuser.Attribute("claim_json", "urn:ibm:names:ITFIM:5.1:accessmanager", claim_json_e));

And this for the decoding:
    var claim_json_e=context.get(Scope.REQUEST, "urn:ibm:security:asf:request:token:attribute", "claim_json");
    var claim_json = new java.lang.String(java.util.Base64.getUrlDecoder().decode(claim_json_e));

Using IDMappingExtCache is a nice option to explore but in our case the claim_json is handed to us in the oidc-rp flow, so there is no user_session_index yet to use as a key.

Thanks!

Regards,
Paul van den Brink

My advice is to either:

1. Perform base64urlencode(JSON.stringify(claim_json)) and store that encoded value in the credential. When it is needed later, perform the reverse decoding to get back to JSON; or 
2. Unless this data is being accessed very regularly, a better option might be to store it in IDMappingExtCache keyed off the user_session_index of the credential so that the credential is not very large since credential headers are usually sent on every request to junctioned servers, and large credentials will have a performance implication.

Hi Team,

I am using ISVA10.0.4.0 IF1

For my usecase I need to preserve the claim_json. I decided to put it in the credential by putting it in an am-eai-xattrs header called: claim_json

I am using this line in my code in my mapping rule:
stsuu.addAttribute(new com.tivoli.am.fim.trustserver.sts.uuser.Attribute("claim_json", "urn:ibm:names:ITFIM:5.1:accessmanager", claim_json));

Now the end user gets an error:
Could not authenticate user. An EAI server returned invalid authentication data. (0x38cf081d)

After some investigation I saw that part of the data in the claim_json is encoded. The character I encountered is: eb Which is the encoding for ë.

Is it even possible to use encoded data in an am-eai-xattrs reponse header?
Or is this a bug in the proxy interpreting the header?

Regards,

Paul van den Brink

Hi Shane,

I checked with the cred-viewer:

Credential Viewer
Username: unauthenticated
Attribute Name    Attribute Value(s)
AZN_CRED_AUTH_EPOCH_TIME    1690365354
AZN_CRED_BROWSER_INFO    Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36 Edg/115.0.1901.183
AZN_CRED_IP_FAMILY    AF_INET
AZN_CRED_MECH_ID    IV_UNAUTH_V3.0
AZN_CRED_NETWORK_ADDRESS_BIN    0xc6121212
AZN_CRED_NETWORK_ADDRESS_STR    10.10.10.10
AZN_CRED_PRINCIPAL_DOMAIN    Default
AZN_CRED_PRINCIPAL_NAME    unauthenticated
AZN_CRED_QOP_INFO    SSK: TLSV12: 9C
AZN_CRED_USER_INFO    unauthenticated
AZN_CRED_VERSION    0x00001004
SMS_SESSION_REALM    ISAM-Distributed-Session-Cache
tagvalue_login_user_name    unauthenticated
tagvalue_session_index    9c2dd8fc-2b9a-11ee-a09c-005056a4f2cc
tagvalue_user_session_id    YWVnb24taW50ZXJuZXQtemFrZWxpamsA_ZMDtqgAAAAIAAAA0qu3AZLhTVlhbfwAANTg5U3BGK0dJT3VBdUVtS2NhL0dqUERjcXBlcFo0eWhETVhaV1NYRjVKQzdyYUpYTUJrPQ==:internet-makkelijk

Both session_index and user_session_id are not in the credential, but they are not in the stsuu available to my mapping rule.

Regards,

Paul van den Brink

------------------------------
Paul van den Brink

Original Message:
Sent: Wed July 26, 2023 04:12 AM
From: Shane Weeden
Subject: Is it possible to use encoded data in an eai response header?

You're using the wrong attribute name. Configure the ivcreds app to see what is available. See: https://community.ibm.com/community/user/security/blogs/shane-weeden1/2020/12/04/rip-epacjsp-2007-2020?CommunityKey=96f617c5-4f90-4eb0-baec-2d0c4c22ab50

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

Original Message:
Sent: Wed July 26, 2023 03:46 AM
From: Paul van den Brink
Subject: Is it possible to use encoded data in an eai response header?

Hi Shane,

I changed the setting in the WRP config.

There is no session_index is the stsuu. Is there another setting involved here?
My mapping rule is part of a federation definition with Federation Protocol "OpenID Connect Relying Party" and Role "Relying Party".
When I try to access the session_index with:
var index = context.get(Scope.REQUEST, "urn:ibm:security:asf:request:header", "session_index");
I get:
ReferenceError: "context" is not defined.

Regards,
Paul van den Brink

------------------------------
Paul van den Brink

Original Message:
Sent: Tue July 25, 2023 04:26 PM
From: Shane Weeden
Subject: Is it possible to use encoded data in an eai response header?

What you have described should work fine however I do want to point out you absolutely can use option 2, even in the oidc-rp use case. Just turn on this in the WRP config file:

[session]

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

Original Message:
Sent: Tue July 25, 2023 07:38 AM
From: Paul van den Brink
Subject: Is it possible to use encoded data in an eai response header?

Hi Shane,

Thanks for the suggestions.

For now I am going with option 1.
I am using this for the encoding:
    var claim_json_e = java.util.Base64.getUrlEncoder().encodeToString(claim_json.getBytes());
    stsuu.addAttribute(new com.tivoli.am.fim.trustserver.sts.uuser.Attribute("claim_json", "urn:ibm:names:ITFIM:5.1:accessmanager", claim_json_e));

And this for the decoding:
    var claim_json_e=context.get(Scope.REQUEST, "urn:ibm:security:asf:request:token:attribute", "claim_json");
    var claim_json = new java.lang.String(java.util.Base64.getUrlDecoder().decode(claim_json_e));

Using IDMappingExtCache is a nice option to explore but in our case the claim_json is handed to us in the oidc-rp flow, so there is no user_session_index yet to use as a key.

Thanks!

Regards,
Paul van den Brink

------------------------------
Paul van den Brink

Original Message:
Sent: Tue July 25, 2023 01:32 AM
From: Shane Weeden
Subject: Is it possible to use encoded data in an eai response header?

My advice is to either:

1. Perform base64urlencode(JSON.stringify(claim_json)) and store that encoded value in the credential. When it is needed later, perform the reverse decoding to get back to JSON; or 
2. Unless this data is being accessed very regularly, a better option might be to store it in IDMappingExtCache keyed off the user_session_index of the credential so that the credential is not very large since credential headers are usually sent on every request to junctioned servers, and large credentials will have a performance implication.

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

Original Message:
Sent: Mon July 24, 2023 09:01 AM
From: Paul van den Brink
Subject: Is it possible to use encoded data in an eai response header?

Hi Team,

I am using ISVA10.0.4.0 IF1

For my usecase I need to preserve the claim_json. I decided to put it in the credential by putting it in an am-eai-xattrs header called: claim_json

I am using this line in my code in my mapping rule:
stsuu.addAttribute(new com.tivoli.am.fim.trustserver.sts.uuser.Attribute("claim_json", "urn:ibm:names:ITFIM:5.1:accessmanager", claim_json));

Now the end user gets an error:
Could not authenticate user. An EAI server returned invalid authentication data. (0x38cf081d)

After some investigation I saw that part of the data in the claim_json is encoded. The character I encountered is: eb Which is the encoding for ë.

Is it even possible to use encoded data in an am-eai-xattrs reponse header?
Or is this a bug in the proxy interpreting the header?

Regards,

Paul van den Brink

------------------------------
Paul van den Brink
------------------------------

You mentioned earlier your context is an OIDC-RP flow, so I guess you're in a JS mapping rule in an OIDC RP Federation? If so, follow these steps:

1. First enable the tagvalue_session_index to be sent in a HTTP header from WebSEAL to the Federation runtime. Assuming your WebSEAL configuration has force-tag-value-prefix = no  and the junction between WebSEAL and the federation runtime is /mga, it will be something like (substitute your WebSEAL server name as needed):

pdadmin sec_master> object list /WebSEAL

    /WebSEAL/localhost-default

pdadmin sec_master> object modify /WebSEAL/localhost-default/mga set attribute HTTP-Tag-Value tagvalue_session_index=session_index

If force-tag-value-prefix = yes in your WebSEAL config file, just remove tagvalue_ from the command above.

2. To get that http header to the STS,  turn on this setting in AAC->Advanced Configuration which will cause extra data to be sent to the WS-Trust service from the federation runtime, populated in the stsuu:
sps.httpRequestClaims.enabled = true

You can tune down sps.httpRequestClaims.filterSpec to send less stuff to the STS, but the default value will also work fine, and definitely start with that set to the default till you get it working.

3. Then in your mapping rule you can access the tagvalue_session_index value with:

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

Original Message:
Sent: Wed July 26, 2023 06:08 AM
From: Paul van den Brink
Subject: Is it possible to use encoded data in an eai response header?

Hi Shane,

I checked with the cred-viewer:

Credential Viewer
Username: unauthenticated
Attribute Name    Attribute Value(s)
AZN_CRED_AUTH_EPOCH_TIME    1690365354
AZN_CRED_BROWSER_INFO    Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36 Edg/115.0.1901.183
AZN_CRED_IP_FAMILY    AF_INET
AZN_CRED_MECH_ID    IV_UNAUTH_V3.0
AZN_CRED_NETWORK_ADDRESS_BIN    0xc6121212
AZN_CRED_NETWORK_ADDRESS_STR    10.10.10.10
AZN_CRED_PRINCIPAL_DOMAIN    Default
AZN_CRED_PRINCIPAL_NAME    unauthenticated
AZN_CRED_QOP_INFO    SSK: TLSV12: 9C
AZN_CRED_USER_INFO    unauthenticated
AZN_CRED_VERSION    0x00001004
SMS_SESSION_REALM    ISAM-Distributed-Session-Cache
tagvalue_login_user_name    unauthenticated
tagvalue_session_index    9c2dd8fc-2b9a-11ee-a09c-005056a4f2cc
tagvalue_user_session_id    YWVnb24taW50ZXJuZXQtemFrZWxpamsA_ZMDtqgAAAAIAAAA0qu3AZLhTVlhbfwAANTg5U3BGK0dJT3VBdUVtS2NhL0dqUERjcXBlcFo0eWhETVhaV1NYRjVKQzdyYUpYTUJrPQ==:internet-makkelijk

Both session_index and user_session_id are not in the credential, but they are not in the stsuu available to my mapping rule.

Regards,

Paul van den Brink

------------------------------
Paul van den Brink

Original Message:
Sent: Wed July 26, 2023 04:12 AM
From: Shane Weeden
Subject: Is it possible to use encoded data in an eai response header?

You're using the wrong attribute name. Configure the ivcreds app to see what is available. See: https://community.ibm.com/community/user/security/blogs/shane-weeden1/2020/12/04/rip-epacjsp-2007-2020?CommunityKey=96f617c5-4f90-4eb0-baec-2d0c4c22ab50

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

Original Message:
Sent: Wed July 26, 2023 03:46 AM
From: Paul van den Brink
Subject: Is it possible to use encoded data in an eai response header?

Hi Shane,

I changed the setting in the WRP config.

There is no session_index is the stsuu. Is there another setting involved here?
My mapping rule is part of a federation definition with Federation Protocol "OpenID Connect Relying Party" and Role "Relying Party".
When I try to access the session_index with:
var index = context.get(Scope.REQUEST, "urn:ibm:security:asf:request:header", "session_index");
I get:
ReferenceError: "context" is not defined.

Regards,
Paul van den Brink

------------------------------
Paul van den Brink

Original Message:
Sent: Tue July 25, 2023 04:26 PM
From: Shane Weeden
Subject: Is it possible to use encoded data in an eai response header?

What you have described should work fine however I do want to point out you absolutely can use option 2, even in the oidc-rp use case. Just turn on this in the WRP config file:

[session]

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

Original Message:
Sent: Tue July 25, 2023 07:38 AM
From: Paul van den Brink
Subject: Is it possible to use encoded data in an eai response header?

Hi Shane,

Thanks for the suggestions.

For now I am going with option 1.
I am using this for the encoding:
    var claim_json_e = java.util.Base64.getUrlEncoder().encodeToString(claim_json.getBytes());
    stsuu.addAttribute(new com.tivoli.am.fim.trustserver.sts.uuser.Attribute("claim_json", "urn:ibm:names:ITFIM:5.1:accessmanager", claim_json_e));

And this for the decoding:
    var claim_json_e=context.get(Scope.REQUEST, "urn:ibm:security:asf:request:token:attribute", "claim_json");
    var claim_json = new java.lang.String(java.util.Base64.getUrlDecoder().decode(claim_json_e));

Using IDMappingExtCache is a nice option to explore but in our case the claim_json is handed to us in the oidc-rp flow, so there is no user_session_index yet to use as a key.

Thanks!

Regards,
Paul van den Brink

------------------------------
Paul van den Brink

Original Message:
Sent: Tue July 25, 2023 01:32 AM
From: Shane Weeden
Subject: Is it possible to use encoded data in an eai response header?

My advice is to either:

1. Perform base64urlencode(JSON.stringify(claim_json)) and store that encoded value in the credential. When it is needed later, perform the reverse decoding to get back to JSON; or 
2. Unless this data is being accessed very regularly, a better option might be to store it in IDMappingExtCache keyed off the user_session_index of the credential so that the credential is not very large since credential headers are usually sent on every request to junctioned servers, and large credentials will have a performance implication.

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

Original Message:
Sent: Mon July 24, 2023 09:01 AM
From: Paul van den Brink
Subject: Is it possible to use encoded data in an eai response header?

Hi Team,

I am using ISVA10.0.4.0 IF1

For my usecase I need to preserve the claim_json. I decided to put it in the credential by putting it in an am-eai-xattrs header called: claim_json

I am using this line in my code in my mapping rule:
stsuu.addAttribute(new com.tivoli.am.fim.trustserver.sts.uuser.Attribute("claim_json", "urn:ibm:names:ITFIM:5.1:accessmanager", claim_json));

Now the end user gets an error:
Could not authenticate user. An EAI server returned invalid authentication data. (0x38cf081d)

After some investigation I saw that part of the data in the claim_json is encoded. The character I encountered is: eb Which is the encoding for ë.

Is it even possible to use encoded data in an am-eai-xattrs reponse header?
Or is this a bug in the proxy interpreting the header?

Regards,

Paul van den Brink

------------------------------
Paul van den Brink
------------------------------