IBM Verify

Migration from tfimsso to jwt stanza has been challenging for us due to several reasons:

1. Absence of a Global JWT Stanza: Unlike [tfimsso], there is no global JWT stanza. Consequently, every junction with JWT necessitates deployment and a restart.

2. AZN_CRED_GROUPS::groups Attribute Format: Inside the JWT stanza, the attr::AZN_CRED_GROUPS::groups attribute returns either a string for one group or an array of strings for multiple groups.

   A. We encounter difficulties with backend servers that do not handle string data.

   B. This means that during our migration from TFIMSSO to JWT, many backends may fail to operate as expected.

According to information from IBM support, this behavior is by design. However, we believe it should be corrected to consistently return either a string or an array.

@Philip Nye and @Shane Weeden, I'm mentioning you in this post because we briefly discussed this issue during our previous meet. You mentioned that it's a straightforward fix, and we can expect a fix pack to ensure that AZN_CRED_GROUPS::groups within the [jwt] stanza always returns an array of strings.

We have attempted to resolve this by adding a dummy group to all users so that the JWT stanza consistently contains multiple groups. Unfortunately, we are uncertain about how to inject a group during Kerberos or Basic/Passwd Authentication.

This is an urgent matter, and any help or guidance you can provide would be greatly appreciated.

I tried adding a dummy group to all authenticated sessions by adding the following inside the AuthSvcCredential

importClass(Packages.com.tivoli.am.fim.trustserver.sts.uuser.Group);stsuu.addGroup(new com.tivoli.am.fim.trustserver.sts.uuser.Group("NoAccessTempGroup","urn:ibm:names:ITFIM:5.1:accessmanager",null));

The code runs fine, but the group is not being added to the credential.

Migration from tfimsso to jwt stanza has been challenging for us due to several reasons:

1. Absence of a Global JWT Stanza: Unlike [tfimsso], there is no global JWT stanza. Consequently, every junction with JWT necessitates deployment and a restart.

2. AZN_CRED_GROUPS::groups Attribute Format: Inside the JWT stanza, the attr::AZN_CRED_GROUPS::groups attribute returns either a string for one group or an array of strings for multiple groups.

   A. We encounter difficulties with backend servers that do not handle string data.

   B. This means that during our migration from TFIMSSO to JWT, many backends may fail to operate as expected.

According to information from IBM support, this behavior is by design. However, we believe it should be corrected to consistently return either a string or an array.

@Philip Nye and @Shane Weeden, I'm mentioning you in this post because we briefly discussed this issue during our previous meet. You mentioned that it's a straightforward fix, and we can expect a fix pack to ensure that AZN_CRED_GROUPS::groups within the [jwt] stanza always returns an array of strings.

We have attempted to resolve this by adding a dummy group to all users so that the JWT stanza consistently contains multiple groups. Unfortunately, we are uncertain about how to inject a group during Kerberos or Basic/Passwd Authentication.

This is an urgent matter, and any help or guidance you can provide would be greatly appreciated.

 First, it will depend on the point of contact type you are using.

If you use Access Manager Credential then the following code will work:

importClass(Packages.com.tivoli.am.fim.trustserver.sts.uuser.Group);importClass(Packages.com.tivoli.am.fim.trustserver.sts.uuser.Attribute);var group = new Group("NoAccessTempGroup", "urn:ibm:names:ITFIM:5.1:accessmanager", null);var g1 = new Attribute("registryid", "urn:ibm:names:ITFIM:5.1:accessmanager", "cn=NoAccessTempGroup,dc=iswga");var g2 = new Attribute("uuid", "urn:ibm:names:ITFIM:5.1:accessmanager", "00000000-0000-0000-0000-000000000000");group.setAttribute(g1);group.setAttribute(g2);stsuu.addGroup(group);

If you are using Access Manager Username and extended attributes then the groups cannot be dynamically added in the manner you are suggesting since WebSEAL will read them from the registry always.

If you are using Non-Access Manager Username, Access Manager groups and extended attributes then you can also use the above code snippet, but for ACL-based access control you'll also need to add all the real groups and the real group UIUDs manually in JS code, which is probably not what you want to do. 

I tried adding a dummy group to all authenticated sessions by adding the following inside the AuthSvcCredential

importClass(Packages.com.tivoli.am.fim.trustserver.sts.uuser.Group);stsuu.addGroup(new com.tivoli.am.fim.trustserver.sts.uuser.Group("NoAccessTempGroup","urn:ibm:names:ITFIM:5.1:accessmanager",null));

The code runs fine, but the group is not being added to the credential.

Migration from tfimsso to jwt stanza has been challenging for us due to several reasons:

1. Absence of a Global JWT Stanza: Unlike [tfimsso], there is no global JWT stanza. Consequently, every junction with JWT necessitates deployment and a restart.

2. AZN_CRED_GROUPS::groups Attribute Format: Inside the JWT stanza, the attr::AZN_CRED_GROUPS::groups attribute returns either a string for one group or an array of strings for multiple groups.

   A. We encounter difficulties with backend servers that do not handle string data.

   B. This means that during our migration from TFIMSSO to JWT, many backends may fail to operate as expected.

According to information from IBM support, this behavior is by design. However, we believe it should be corrected to consistently return either a string or an array.

@Philip Nye and @Shane Weeden, I'm mentioning you in this post because we briefly discussed this issue during our previous meet. You mentioned that it's a straightforward fix, and we can expect a fix pack to ensure that AZN_CRED_GROUPS::groups within the [jwt] stanza always returns an array of strings.

We have attempted to resolve this by adding a dummy group to all users so that the JWT stanza consistently contains multiple groups. Unfortunately, we are uncertain about how to inject a group during Kerberos or Basic/Passwd Authentication.

This is an urgent matter, and any help or guidance you can provide would be greatly appreciated.

Thanks

We are using Non-Access Manager Username, Access Manager groups and extended attributes.
What would be the suggested approach? I take it from what you wrote that even if we can make it work this way it's not adviceable.

We don't have any open ideas etc with IBM regarding the array.

 First, it will depend on the point of contact type you are using.

If you use Access Manager Credential then the following code will work:

importClass(Packages.com.tivoli.am.fim.trustserver.sts.uuser.Group);importClass(Packages.com.tivoli.am.fim.trustserver.sts.uuser.Attribute);var group = new Group("NoAccessTempGroup", "urn:ibm:names:ITFIM:5.1:accessmanager", null);var g1 = new Attribute("registryid", "urn:ibm:names:ITFIM:5.1:accessmanager", "cn=NoAccessTempGroup,dc=iswga");var g2 = new Attribute("uuid", "urn:ibm:names:ITFIM:5.1:accessmanager", "00000000-0000-0000-0000-000000000000");group.setAttribute(g1);group.setAttribute(g2);stsuu.addGroup(group);

If you are using Access Manager Username and extended attributes then the groups cannot be dynamically added in the manner you are suggesting since WebSEAL will read them from the registry always.

If you are using Non-Access Manager Username, Access Manager groups and extended attributes then you can also use the above code snippet, but for ACL-based access control you'll also need to add all the real groups and the real group UIUDs manually in JS code, which is probably not what you want to do. 

I tried adding a dummy group to all authenticated sessions by adding the following inside the AuthSvcCredential

importClass(Packages.com.tivoli.am.fim.trustserver.sts.uuser.Group);stsuu.addGroup(new com.tivoli.am.fim.trustserver.sts.uuser.Group("NoAccessTempGroup","urn:ibm:names:ITFIM:5.1:accessmanager",null));

The code runs fine, but the group is not being added to the credential.

Migration from tfimsso to jwt stanza has been challenging for us due to several reasons:

1. Absence of a Global JWT Stanza: Unlike [tfimsso], there is no global JWT stanza. Consequently, every junction with JWT necessitates deployment and a restart.

2. AZN_CRED_GROUPS::groups Attribute Format: Inside the JWT stanza, the attr::AZN_CRED_GROUPS::groups attribute returns either a string for one group or an array of strings for multiple groups.

   A. We encounter difficulties with backend servers that do not handle string data.

   B. This means that during our migration from TFIMSSO to JWT, many backends may fail to operate as expected.

According to information from IBM support, this behavior is by design. However, we believe it should be corrected to consistently return either a string or an array.

@Philip Nye and @Shane Weeden, I'm mentioning you in this post because we briefly discussed this issue during our previous meet. You mentioned that it's a straightforward fix, and we can expect a fix pack to ensure that AZN_CRED_GROUPS::groups within the [jwt] stanza always returns an array of strings.

We have attempted to resolve this by adding a dummy group to all users so that the JWT stanza consistently contains multiple groups. Unfortunately, we are uncertain about how to inject a group during Kerberos or Basic/Passwd Authentication.

This is an urgent matter, and any help or guidance you can provide would be greatly appreciated.

I tried adding a dummy group to all authenticated sessions by adding the following inside the AuthSvcCredential

importClass(Packages.com.tivoli.am.fim.trustserver.sts.uuser.Group);stsuu.addGroup(new com.tivoli.am.fim.trustserver.sts.uuser.Group("NoAccessTempGroup","urn:ibm:names:ITFIM:5.1:accessmanager",null));

The code runs fine, but the group is not being added to the credential.

Migration from tfimsso to jwt stanza has been challenging for us due to several reasons:

1. Absence of a Global JWT Stanza: Unlike [tfimsso], there is no global JWT stanza. Consequently, every junction with JWT necessitates deployment and a restart.

2. AZN_CRED_GROUPS::groups Attribute Format: Inside the JWT stanza, the attr::AZN_CRED_GROUPS::groups attribute returns either a string for one group or an array of strings for multiple groups.

   A. We encounter difficulties with backend servers that do not handle string data.

   B. This means that during our migration from TFIMSSO to JWT, many backends may fail to operate as expected.

According to information from IBM support, this behavior is by design. However, we believe it should be corrected to consistently return either a string or an array.

@Philip Nye and @Shane Weeden, I'm mentioning you in this post because we briefly discussed this issue during our previous meet. You mentioned that it's a straightforward fix, and we can expect a fix pack to ensure that AZN_CRED_GROUPS::groups within the [jwt] stanza always returns an array of strings.

We have attempted to resolve this by adding a dummy group to all users so that the JWT stanza consistently contains multiple groups. Unfortunately, we are uncertain about how to inject a group during Kerberos or Basic/Passwd Authentication.

This is an urgent matter, and any help or guidance you can provide would be greatly appreciated.

Do you have an idea open for the first question (always returning an array)? I don't know of any work going on in that area.

I tried adding a dummy group to all authenticated sessions by adding the following inside the AuthSvcCredential

importClass(Packages.com.tivoli.am.fim.trustserver.sts.uuser.Group);stsuu.addGroup(new com.tivoli.am.fim.trustserver.sts.uuser.Group("NoAccessTempGroup","urn:ibm:names:ITFIM:5.1:accessmanager",null));

The code runs fine, but the group is not being added to the credential.

Migration from tfimsso to jwt stanza has been challenging for us due to several reasons:

1. Absence of a Global JWT Stanza: Unlike [tfimsso], there is no global JWT stanza. Consequently, every junction with JWT necessitates deployment and a restart.

2. AZN_CRED_GROUPS::groups Attribute Format: Inside the JWT stanza, the attr::AZN_CRED_GROUPS::groups attribute returns either a string for one group or an array of strings for multiple groups.

   A. We encounter difficulties with backend servers that do not handle string data.

   B. This means that during our migration from TFIMSSO to JWT, many backends may fail to operate as expected.

According to information from IBM support, this behavior is by design. However, we believe it should be corrected to consistently return either a string or an array.

@Philip Nye and @Shane Weeden, I'm mentioning you in this post because we briefly discussed this issue during our previous meet. You mentioned that it's a straightforward fix, and we can expect a fix pack to ensure that AZN_CRED_GROUPS::groups within the [jwt] stanza always returns an array of strings.

We have attempted to resolve this by adding a dummy group to all users so that the JWT stanza consistently contains multiple groups. Unfortunately, we are uncertain about how to inject a group during Kerberos or Basic/Passwd Authentication.

This is an urgent matter, and any help or guidance you can provide would be greatly appreciated.

I am not sure if others can vote on ideas, but I would cast my vote for both these ideas.  I've always thought a global JWT option would be extremely useful to prevent restarts.  I suppose then an option would need to exist on junctions to turn the JWT on/off for each junction, unless you just threw it there blindly each time.  Granted, we're mostly invested in containers now which you cannot add junctions on the fly to without a container restart.  However, a central option for the numerous junctions we may use this on would reduce maintenance overhead.

I had a similar issue of the group being a string versus an array on JWT.  The issue was on JWT access tokens and ID tokens.  We had an application team whose library could not deal with the string.  Since this was obviously going through the RTSS, I modified our mapping rules to ensure we always sent the value as an array.  But I can definitely see the concern here as I had to address something similar a couple years ago.

Do you have an idea open for the first question (always returning an array)? I don't know of any work going on in that area.

I tried adding a dummy group to all authenticated sessions by adding the following inside the AuthSvcCredential

importClass(Packages.com.tivoli.am.fim.trustserver.sts.uuser.Group);stsuu.addGroup(new com.tivoli.am.fim.trustserver.sts.uuser.Group("NoAccessTempGroup","urn:ibm:names:ITFIM:5.1:accessmanager",null));

The code runs fine, but the group is not being added to the credential.

Migration from tfimsso to jwt stanza has been challenging for us due to several reasons:

1. Absence of a Global JWT Stanza: Unlike [tfimsso], there is no global JWT stanza. Consequently, every junction with JWT necessitates deployment and a restart.

2. AZN_CRED_GROUPS::groups Attribute Format: Inside the JWT stanza, the attr::AZN_CRED_GROUPS::groups attribute returns either a string for one group or an array of strings for multiple groups.

   A. We encounter difficulties with backend servers that do not handle string data.

   B. This means that during our migration from TFIMSSO to JWT, many backends may fail to operate as expected.

According to information from IBM support, this behavior is by design. However, we believe it should be corrected to consistently return either a string or an array.

@Philip Nye and @Shane Weeden, I'm mentioning you in this post because we briefly discussed this issue during our previous meet. You mentioned that it's a straightforward fix, and we can expect a fix pack to ensure that AZN_CRED_GROUPS::groups within the [jwt] stanza always returns an array of strings.

We have attempted to resolve this by adding a dummy group to all users so that the JWT stanza consistently contains multiple groups. Unfortunately, we are uncertain about how to inject a group during Kerberos or Basic/Passwd Authentication.

This is an urgent matter, and any help or guidance you can provide would be greatly appreciated.