SSO LTPA/JWT support authentication filter for Liberty

[rbacalzo]

WAD for SSO LTPA/JWT support authentication filter:
https://ibm.box.com/s/hv3ftnr3dsa294j37pu153b5jdyi8fk8

Doc: OpenLiberty/docs#3801

In This epic we are adding only the SSO LTPA/JWT support authentication filter.

Recently a few developers who had experienced issues with WebSphere Liberty SSO in the past were asked to provide input on a new Liberty LTPA authentication filter mechanism under consideration for development.

Below is a summary of the responses:

---

The LTPA authentication filter sounds like a good idea. I think it should work similarly to the authentication filter used by OIDC (
https://www.ibm.com/support/knowledgecenter/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/rwlp_auth_filter.html and https://www.ibm.com/support/knowledgecenter/SSEQTP_liberty/com.ibm.websphere.liberty.autogen.nd.doc/ae/rwlp_config_openidConnectClient.html).

But I would give this priority to the filter implementation:

1. If there is a Bearer token on the HTTP Authorization header, then ignore LTPA cookie and do not attempt any LTPA authentication (this is really just a specific case of Fix branding to be Open Liberty rather than WebSphere Liberty #2 below)
2. If there is a specific HTTP Header, then do not attempt any LTPA authentication
3. If there is a specific Cookie or a value for a cookie, then do not attempt any LTPA authentication
4. If there is a specific string in the HTTP Request URL (including request parameters), then do not attempt any LTPA authentication

In terms of APIs, these would be the most useful:

1. Enance the OIDC PropagationHelper (https://www.ibm.com/support/knowledgecenter/en/SSEQTP_liberty/com.ibm.websphere.javadoc.liberty.doc/com.ibm.websphere.appserver.api.oidc_1.0-javadoc/com/ibm/websphere/security/openidconnect/PropagationHelper.html) to return a String version of the IdToken (e.g. getTokenString()). If propagating an IdToken to a downstream server as a Bearer token on the http authorization header, this needs to be a string. The current method getIdToken() returns a com.ibm.websphere.security.openidconnect.token.IdToken object. This is useless for token propagation since you can't get the String form of that token to propagate to a subsequent downstream servers.

2. A public method to validate an LTPA token.

It would also be good to know a way of identifying tWAS and Liberty jar files required for builds when we do use specific Liberty or tWAS APIs in our code so that we can have the correct build dependencies. Right now, we have to dig through Liberty and tWAS deployed directories to search for the jars containing the classes we need to compile our code, then manually copy those jars into our build tree.

---

I think we had less experience needing to manipulate the application of LTPA checks, and more with limitations around various SSO TAIs (i.e. SAML, SPNEGO) needing more advanced filtering behavior in cases of multiple IdP or some users with native login, some with SSO, so I hope I'm understanding the request.

Anyway, For LTPA filter ideas I think I would rank as follows

1. One more more Request URL patterns
2. Presence of specific cookies and values
3. Presence of other tokens in the headers.. (for us, this is primarily SAMLv2)
4. A range of ip addresses
5. One or more remote ip address
6. Some browser information (IE, Firefox, Safari) ..
   I would also think that it's very important to have a robust logical operations supported in whatever the filter mechanism (i.e. grouping of filter expressions with AND and OR logical operators, usage of NOT). I recall SAML sp.filter having some limitations around being all AND or all OR in certain expressions.

I would imagine it would be useful having a per-User API that allows the application to set a cookie so that the LTPA authentication could be by-passed next time if needed for that user ( a formal way for us to decide which users might have cookies that will be filtered out by #2 above )

[una-tapa]

This is from the stack product leads I had opportunities to work with. This git issue include great ideas on filtering out ltpa token for easier security configuration . Roger Bacalzo kindly put together his ideas with Brian Laskey's. These are from real customers scenarios and their day-to-day experience developing on Liberty.

[garypicher]

Design review follow-up actions:

• Is similar support available for JWT? If so, ensure that this support is consistent. If not, come up with a plan to add similar support for JWT under this feature or a different feature.

[nickolas-potvin]

Would it be possible to also get these filters for custom TAIs?

[utle]

#12859

[utle]

@garypicher
yes, we update the WAD for JWT SSO feature to support authentication filter

[utle]

LTPASSO authFIlter DEV: #13800
LTPASSO authFilter FAT: #13801
LTPASSO authFilter Feature test summary: #14861
JWTSSO authFilter DEV: #13802
JWTSSO authFilter FAT: #13803
JWTSSO authFilter Feature test summary: #13804

[NottyCode]

@utle do you have any reference to work items to track the documentation work for auth filters? In the design review we spoke about deficiencies in current documentation so I'd like to make sure we have documentation issues raised somewhere before I approve.

[utle]

Hi @NottyCode Here is the issue for auth filter description and sample. [https://github.com//issues/11741]
The Open Liberty Document also has an article for Authentication Filter.

[utle]

Feature Test Summary -
JWT: #13804
LTPA: #14861

[utle]

Hi @donbourne

Serviceability Approval Comment - Please answer the following questions for serviceability approval:

UFO -- does the UFO identify the most likely problems customers will see and identify how the feature will enable them to diagnose and solve those problems without resorting to raising a PMR? Yes Have these issues been addressed in the implementation? Yes

Test and Demo -- As part of the serviceability process we're asking feature teams to test and analyze common problem paths for serviceability and demo those problem paths to someone not involved in the development of the feature (eg. L2, test team, or another development team).
a) What problem paths were tested and demonstrated?

• User has a valid JWT, then tries to access a protected resource using the JWT, if JWTSSO authfilter does not match the requested resource then the user is prompted to login credentials.

• User has a valid JWT, then tries to access a protected resource using the JWT, if JWTSSO authfilter does match the requested resource then the user successfully authenticates with the JWT and reaches the protected resource.

• If the authfilterRef is invalid (including blank ("") ) then the server will issue a warning message CWWKG0033W: The value [] specified for the reference attribute [authFilterRef] was not found in the configuration. The server will treat it as if there is no authFilter and use JWTSSO for all protected resources.

b) Who did you demo to?

• Core Security Team

c) Do the people you demo'd to agree that the serviceability of the demonstrated problem scenarios is sufficient to avoid PMRs for any problems customers are likely to encounter, or that L2 should be able to quickly address those problems without need to engage L3?

• Yes

SVT -- SVT team is often the first team to try new features and often encounters problems setting up and using them. Note that we're not expecting SVT to do full serviceability testing -- just to sign-off on the serviceability of the problem paths they encountered.
a) Who conducted SVT tests for this feature?

• UFO marked for no SVT.
  b) Do they agree that the serviceability of the problems they encountered is sufficient to avoid PMRs, or that L2 should be able to quickly address those problems without need to engage L3?
• n/a

Which L2 / L3 queues will handle PMRs for this feature?

• WAS: L2 SEC Team
• WAS: L3 Core Security

Does this feature add any new metrics or emit any new JSON events? If yes, have you updated the JMX metrics reference list / Metrics reference list / JSON log events reference list in the Open Liberty docs?

• No new metrics or JSON events

[chirp1]

The input that Ut provided for the ID issue looks good. Approving.

[utle]

GA Blog - #16552