Given a user who has already authenticated, is it possible to add new or modify existing extended attributes in the user CRED? Programmatically through Infomap, perhaps or a service called through EAI?

Thanks.

------------------------------
Jose Negron
Managing Consultant
IBM
555-555-5555
------------------------------

Jose,

An application server which sits behind a Reverse Proxy junction has full control over the extended attributes which are added to the credential that is built when it responds using EAI to a defined trigger URL.  The easiest way to implement a service which can do this job is to write it as a custom JavaScript authentication mechanism in the AAC module (if you have this in your environment).  That way the AAC authentication service framework takes care of extracting the current attributes from the credential so you can return them again (as-is, omitted, or modified).

Note that an EAI cannot modify the built-in credential attributes (most of those starting AZN_CRED).  These are protected.

To force all users to login and then complete the EAI flow, you would most likely use authentication levels.  Make all your "real" pages level 2 and set this level in EAI.  That way after a user logs in (and gets level 1) a step-up will immediately be triggered which you can use to call the service that will use EAI to add the extra attributes.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------

Original Message:
Sent: Mon April 12, 2021 11:53 AM
From: Jose Negron
Subject: Modifying Existing User Cred with new/updated extended attributes?

Given a user who has already authenticated, is it possible to add new or modify existing extended attributes in the user CRED? Programmatically through Infomap, perhaps or a service called through EAI?

Thanks.

------------------------------
Jose Negron
Managing Consultant
IBM
555-555-5555
------------------------------

Current train of thought was leveraging a federation mapping rule and the service which that mapping rule calls. Once a user has authenticated (federated authn) the user would traverse the application space and re-engage that same mapping rule/backend service through specially constructed links. This isn't working quite as expected (or hoped).

Reading your response, sounds like triggering step up would be a way of triggering a call where the end result is adding/editing the extra attribute? To the user's original CRED?

Thank you.

------------------------------
Jose Negron
------------------------------

Original Message:
Sent: Mon April 12, 2021 02:09 PM
From: Jon Harry
Subject: Modifying Existing User Cred with new/updated extended attributes?

Jose,

An application server which sits behind a Reverse Proxy junction has full control over the extended attributes which are added to the credential that is built when it responds using EAI to a defined trigger URL.  The easiest way to implement a service which can do this job is to write it as a custom JavaScript authentication mechanism in the AAC module (if you have this in your environment).  That way the AAC authentication service framework takes care of extracting the current attributes from the credential so you can return them again (as-is, omitted, or modified).

Note that an EAI cannot modify the built-in credential attributes (most of those starting AZN_CRED).  These are protected.

To force all users to login and then complete the EAI flow, you would most likely use authentication levels.  Make all your "real" pages level 2 and set this level in EAI.  That way after a user logs in (and gets level 1) a step-up will immediately be triggered which you can use to call the service that will use EAI to add the extra attributes.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM

Original Message:
Sent: Mon April 12, 2021 11:53 AM
From: Jose Negron
Subject: Modifying Existing User Cred with new/updated extended attributes?

Given a user who has already authenticated, is it possible to add new or modify existing extended attributes in the user CRED? Programmatically through Infomap, perhaps or a service called through EAI?

Thanks.

------------------------------
Jose Negron
Managing Consultant
IBM
555-555-5555
------------------------------

Jose,

If the user is authenticating via a federation, then you should probably populate all the required attributes in the mapping rule that is invoked as part of the Service Provider processing.

If you need information from the local user registry to calculate these extra attributes you should be able to call out using the LDAP lookup helper or by using a nested STS call to another STS chain that uses the LDAP lookup module.

Have a look in the federation cookbook for some info on this neared method. HTTPS://ibm.biz/isamfedcookbook.

Jon. 

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------

Original Message:
Sent: Mon April 12, 2021 02:58 PM
From: Jose Negron
Subject: Modifying Existing User Cred with new/updated extended attributes?

Current train of thought was leveraging a federation mapping rule and the service which that mapping rule calls. Once a user has authenticated (federated authn) the user would traverse the application space and re-engage that same mapping rule/backend service through specially constructed links. This isn't working quite as expected (or hoped).

Reading your response, sounds like triggering step up would be a way of triggering a call where the end result is adding/editing the extra attribute? To the user's original CRED?

Thank you.

------------------------------
Jose Negron

Original Message:
Sent: Mon April 12, 2021 02:09 PM
From: Jon Harry
Subject: Modifying Existing User Cred with new/updated extended attributes?

Jose,

An application server which sits behind a Reverse Proxy junction has full control over the extended attributes which are added to the credential that is built when it responds using EAI to a defined trigger URL.  The easiest way to implement a service which can do this job is to write it as a custom JavaScript authentication mechanism in the AAC module (if you have this in your environment).  That way the AAC authentication service framework takes care of extracting the current attributes from the credential so you can return them again (as-is, omitted, or modified).

Note that an EAI cannot modify the built-in credential attributes (most of those starting AZN_CRED).  These are protected.

To force all users to login and then complete the EAI flow, you would most likely use authentication levels.  Make all your "real" pages level 2 and set this level in EAI.  That way after a user logs in (and gets level 1) a step-up will immediately be triggered which you can use to call the service that will use EAI to add the extra attributes.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM

Original Message:
Sent: Mon April 12, 2021 11:53 AM
From: Jose Negron
Subject: Modifying Existing User Cred with new/updated extended attributes?

Given a user who has already authenticated, is it possible to add new or modify existing extended attributes in the user CRED? Programmatically through Infomap, perhaps or a service called through EAI?

Thanks.

------------------------------
Jose Negron
Managing Consultant
IBM
555-555-5555
------------------------------

Thanks for your suggestions Jon. Few things here we'll need to review.

------------------------------
Jose Negron
------------------------------

Original Message:
Sent: Mon April 12, 2021 03:09 PM
From: Jon Harry
Subject: Modifying Existing User Cred with new/updated extended attributes?

Jose,

If the user is authenticating via a federation, then you should probably populate all the required attributes in the mapping rule that is invoked as part of the Service Provider processing.

If you need information from the local user registry to calculate these extra attributes you should be able to call out using the LDAP lookup helper or by using a nested STS call to another STS chain that uses the LDAP lookup module.

Have a look in the federation cookbook for some info on this neared method. HTTPS://ibm.biz/isamfedcookbook.

Jon. 

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM

Original Message:
Sent: Mon April 12, 2021 02:58 PM
From: Jose Negron
Subject: Modifying Existing User Cred with new/updated extended attributes?

Current train of thought was leveraging a federation mapping rule and the service which that mapping rule calls. Once a user has authenticated (federated authn) the user would traverse the application space and re-engage that same mapping rule/backend service through specially constructed links. This isn't working quite as expected (or hoped).

Reading your response, sounds like triggering step up would be a way of triggering a call where the end result is adding/editing the extra attribute? To the user's original CRED?

Thank you.

------------------------------
Jose Negron

Original Message:
Sent: Mon April 12, 2021 02:09 PM
From: Jon Harry
Subject: Modifying Existing User Cred with new/updated extended attributes?

Jose,

An application server which sits behind a Reverse Proxy junction has full control over the extended attributes which are added to the credential that is built when it responds using EAI to a defined trigger URL.  The easiest way to implement a service which can do this job is to write it as a custom JavaScript authentication mechanism in the AAC module (if you have this in your environment).  That way the AAC authentication service framework takes care of extracting the current attributes from the credential so you can return them again (as-is, omitted, or modified).

Note that an EAI cannot modify the built-in credential attributes (most of those starting AZN_CRED).  These are protected.

To force all users to login and then complete the EAI flow, you would most likely use authentication levels.  Make all your "real" pages level 2 and set this level in EAI.  That way after a user logs in (and gets level 1) a step-up will immediately be triggered which you can use to call the service that will use EAI to add the extra attributes.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM

Original Message:
Sent: Mon April 12, 2021 11:53 AM
From: Jose Negron
Subject: Modifying Existing User Cred with new/updated extended attributes?

Given a user who has already authenticated, is it possible to add new or modify existing extended attributes in the user CRED? Programmatically through Infomap, perhaps or a service called through EAI?

Thanks.

------------------------------
Jose Negron
Managing Consultant
IBM
555-555-5555
------------------------------

Hi Jon:

How does the Reverse Proxy generates the built-in credential properties? Where does he get that information?
What is the relationship between AZN_CRED and IV-??? Headers, if any?
Do AZN_CRED parameters get passed to the backend server?

------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994
------------------------------

Original Message:
Sent: Mon April 12, 2021 02:09 PM
From: Jon Harry
Subject: Modifying Existing User Cred with new/updated extended attributes?

Jose,

An application server which sits behind a Reverse Proxy junction has full control over the extended attributes which are added to the credential that is built when it responds using EAI to a defined trigger URL.  The easiest way to implement a service which can do this job is to write it as a custom JavaScript authentication mechanism in the AAC module (if you have this in your environment).  That way the AAC authentication service framework takes care of extracting the current attributes from the credential so you can return them again (as-is, omitted, or modified).

Note that an EAI cannot modify the built-in credential attributes (most of those starting AZN_CRED).  These are protected.

To force all users to login and then complete the EAI flow, you would most likely use authentication levels.  Make all your "real" pages level 2 and set this level in EAI.  That way after a user logs in (and gets level 1) a step-up will immediately be triggered which you can use to call the service that will use EAI to add the extra attributes.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM

Original Message:
Sent: Mon April 12, 2021 11:53 AM
From: Jose Negron
Subject: Modifying Existing User Cred with new/updated extended attributes?

Given a user who has already authenticated, is it possible to add new or modify existing extended attributes in the user CRED? Programmatically through Infomap, perhaps or a service called through EAI?

Thanks.

------------------------------
Jose Negron
Managing Consultant
IBM
555-555-5555
------------------------------

Hi Joao,

The "built-in" attribtutes are added when the Reverse Proxy builds the credential.  This can be as a result of it performing authentication itself, or when it builds the credential after an authentication by service connected by EAI (AAC/Federation/custom login service).  They cannot be overridden - unless you can affect the incoming information on which they are based.

This table shows where information in a credential comes from when a Reverse Proxy performs a password login. (This doesn't show group attributes but they are similar).

Built-in password mechanism
AZN_CRED_AUTHNMECH_INFO

Reverse Proxy
AUTHENTICATION_LEVEL
AZN_CRED_AUTH_METHOD
AZN_CRED_USER_INFO
AZN_CRED_QOP_INFO
AZN_CRED_BROWSER_INFO
AZN_CRED_IP_FAMILY
AZN_CRED_NETWORK_ADDRESS_BIN
AZN_CRED_NETWORK_ADDRESS_STR

Verify Access core
AZN_CRED_PRINCIPAL_DOMAIN
AZN_CRED_PRINCIPAL_NAME
AZN_CRED_PRINCIPAL_UUID
AZN_CRED_MECH_ID
AZN_CRED_AUTHZN_ID
AZN_CRED_REGISTRY_ID
AZN_CRED_VERSION

Reverse Proxy Cred Modification
tagvalue_login_user_name
tagvalue_session_index

Cred-Attr Service
(tagvalue_)custom-attribute

The IV headers come directly from these attributes.  For example:
  The IV-USER header comes from AZN_CRED_PRINCIPAL_NAME.
  The IV-GROUPS header comes from AZN_CRED_GROUPS.

Other attributes can be passed in HTTP headers using the HTTP-Tag-Value support.  To use this you must add an extended attribute to the junction object (in objectspace) with case-sensitive name: HTTP-Tag-Value and value: <cred_attr>=<header_name>

Originally, protection was added to prevent the built-in credential attributes from being passed to the backend in headers.  All extended attributes were prepended with tagvalue_ when added to the credential and the name was prepended with tagvalue_ when retrieving attributes from credential.

This turned out to be an annoying limitation so a config parameter was added to remove the "force" of tagvalue_.

When force-tag-value-prefix parameter is set to no, attributes add and lookup operations do NOT have tagvalue_ prepended.  This means that lookups can return any attribute.

Jon.


------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------

Original Message:
Sent: Wed April 14, 2021 04:53 AM
From: Joao Goncalves
Subject: Modifying Existing User Cred with new/updated extended attributes?

Hi Jon:

How does the Reverse Proxy generates the built-in credential properties? Where does he get that information?
What is the relationship between AZN_CRED and IV-??? Headers, if any?
Do AZN_CRED parameters get passed to the backend server?

------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994

Original Message:
Sent: Mon April 12, 2021 02:09 PM
From: Jon Harry
Subject: Modifying Existing User Cred with new/updated extended attributes?

Jose,

An application server which sits behind a Reverse Proxy junction has full control over the extended attributes which are added to the credential that is built when it responds using EAI to a defined trigger URL.  The easiest way to implement a service which can do this job is to write it as a custom JavaScript authentication mechanism in the AAC module (if you have this in your environment).  That way the AAC authentication service framework takes care of extracting the current attributes from the credential so you can return them again (as-is, omitted, or modified).

Note that an EAI cannot modify the built-in credential attributes (most of those starting AZN_CRED).  These are protected.

To force all users to login and then complete the EAI flow, you would most likely use authentication levels.  Make all your "real" pages level 2 and set this level in EAI.  That way after a user logs in (and gets level 1) a step-up will immediately be triggered which you can use to call the service that will use EAI to add the extra attributes.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM

Original Message:
Sent: Mon April 12, 2021 11:53 AM
From: Jose Negron
Subject: Modifying Existing User Cred with new/updated extended attributes?

Given a user who has already authenticated, is it possible to add new or modify existing extended attributes in the user CRED? Programmatically through Infomap, perhaps or a service called through EAI?

Thanks.

------------------------------
Jose Negron
Managing Consultant
IBM
555-555-5555
------------------------------