APSZOS-272 - Add and support AMR claim in JWT

[atosak]

Resolves RFE [266680](RFE: https://wasrtc.hursley.ibm.com:9443/jazz/web/projects/External%20Request%20For%20Enhancements#action=com.ibm.team.workitem.viewWorkItem&id=266680)

[chunlongliang-ibm]

amrValues: This is a new configuration property to jwtConsumer and it accepts a string value which can include multiple values separated by comma.

The behavior is as follows:

• When amrValues is set as a single string like "OTP iris", we expect JWT to include the values specified in the amr claim such as "amr": ["OPT", "iris"]. It is acceptable even if the JWT includes more values such as"amr": ["OPT", "iris", "pwd", "kba"] as long as the specified values are present.

• When amrValues is set as comma separated string (array) like "OTP iris, pwd kba", we expect JWT to include either element from the array and not anything else in the amr claim such as "amr": ["OPT", "iris"] or "amr": ["pwd", "kba"]

• If amrValues is not configured there is no default behavior

amrInclude: This is a new configuration property to jwtBuilder and it accepts a string value which can include multiple values separated by comma.

The behavior is as follows:

• When amrInclude is set as "attribute1 attribute2", the jwtBuilder will search subject's security attributes for attribute1, and attribute2, and include their values as "amr" claim.

• If the property is not found in subject security, the builder will not include them in the "amr" claim.

NOTE: The property names mentioned in the comments has been changed for clarity. authenticationMethodsReferences is changed to amrValues and includeAttributesToAmr is changed to amrInclude

[chunlongliang-ibm]

1. First add the configuration property
2. runtime enforce rules defined in configuration.
3. There is not default behavior change if property is not configured

[chunlongliang-ibm]

my previous comments discussed about JWT consuming. Reading email from stack holder, there is another part of requirements that Liberty (as token issuer) need assert "amr" in JWT. Given that core Liberty security does not have "arm" concept, and does not track information can be used to construct "amr", we could offer option to build "amr" as required by the stack holder. This stack holder does its own credential mapping, so it should have a way to add "arm" related information in subject. The proposal is to add a configuration property to JwtBuilder, which tells Liberty to fetch security attributes from subject as "amr". The assumption is stack holder is responsible to include "amr" data in subject. The design is like this: new property: includeAttributesToAmr (you may want to give a better name). For example, if includeAttributesToAmr ="attribute1 attribute2" The jwtBuilder must search subject's security attributes for attribute1, and attribute2, and include their values as "amr" claim.

[brutif]

Hi @chunlongliang-ibm,

• I understand the need to add checking to the consumer side. For the builder side, they could do that today programmatically, do we know if the ability to do it through server configuration instead is a firm part of the rfe, vs. a nice-to-have?
  • Should the consumer attribute be specifiable in mp-jwt and/or jwtsso feature configuration, or just jwt-1.0 feature configuration?

@AlvinChacko fyi.

[AlvinChacko]

Hi @chunlongliang-ibm,

Do you have an update on the above?

[chunlongliang-ibm]

For builder, there is no way doing it by configuration only, as core Liberty security subject does not have knowledge about 'amr' For consumer, you can do it in jwtBuilder, as mpJwt and jwtSso all reference to jwtBuilder

[NottyCode]

@teddyjtorres We need to get the description updated with the proposed design before I can consider whether or not a design socialization is required. The comment from @chunlongliang-ibm is confusing to me as a design since it talks about arrays in two different ways. I would like to see this clarified in the description prior to any delivery.

[AlvinChacko]

This feature introduces a new jwtBuilder and jwtConsumer configuration property to include the AMR claims in the jwt token. In the jwtBuilder, ‘amrInclude’ can be used to specify the subject properties to include in the amr part of the token. In the jwtConsumer, ‘amrValues’ can be used to specify the values included in the incoming jwt token which is then verified accordingly.

[AlvinChacko]

@NottyCode @teddyjtorres has asked me to write a description. Let me know if it makes sense

[NottyCode]

@AlvinChacko I'd like to get comment 0 updated. In terms of the description I don't know what an amrInclude or amrValues is and what they do which makes it difficult to assess whether you are doing what is required. Also you need to provide the types for the new attributes. Part of the no design approval request is to work out if it is eligible for the fast track process or requires a full design. So I need to be confident that this is simple enough not to require SVT or docs work.

[AlvinChacko]

@NottyCode Have you taken a look at comment. I updated a while back

[samwatibm]

RFE moved to https://cloud-platform.ideas.aha.io/ideas/TWAS-I-214

[garypicher]

This work is partially complete, but the team that was working on it was temporarily moved elsewhere, so I am removing the "In Progress" label until someone is able to pick this up again.