Hello Ed,

I would probably make this a lot simpler here.

We are trying to build profiles that “work out of the box”. With that in mind, OAuth1.0a must be a requirement and OAuth2 should be implemented with the future (and better security) in mind.

Then we need to explicit for a client how to determine if OAuth2 is available, in which case he should use OAuth2, or else fallback to OAuth1.0a.

Only thing then IMO is the way ELM (as a client) determines whether the other side supports OAuth2 / OIDC, if any. That’s what most needs to be clarified. And if that’s by reading some IBM-only property “jd:jsaSsoEnabled” in the rootservices, then doing x, y and z… well that’s all fine. It just needs to be clarified and documented in the profiles.

Hello All,

After further consideration of the authentication section for our OSLC Link Profile, I would like to suggest that someone from IBM needs to write this. Because, while I do have plenty of experience with authentication and OSLC, I don’t know the details of IBM-ELM’s implementation. I requested an audience with John Vasta, to remedy this but this was denied. Perhaps IBMers might find it easier to get a few moments of his time.

At issue here is to what degree IBM-ELM supports OIDC. In my view if IBM-ELM  supported OIDC properly (as I’ll describe below), then the authentication section could be short and simple.

Since IBM-ELM 7.0.1 (I think), when configured with JAS – and using an external OIDC authentication provider - it was possible to send an incoming  request authenticated with OIDC to IBM-ELM (e.g. a resource GET). The problem was that outgoing requests from IBM-ELM (e.g. reading rich hovers, compact rendering, and TRS feeds) still used OAuth 10a. I don’t know of this is still the case.

So my questions to John Vasta are:

Regarding IBM-ELM support of OIDC – especially when using an external OIDC authentication provider (e.g. keycloak, or Ping) in a the typical SSO configuration

1. Are HTTP requests received by IBM-ELM supported which have bearer tokens from the external OIDC authentication provider (assuming properly configured with JAS) – This should be YES since 7.0.1 or so.
2. Are HTTP requests leaving IBM-ELM signed by the external OIDC authentication provider (e.g. keycloak or ping) and not just JAS/Liberty. - As far as I know this is NO

Regarding usage of functional users (aka technical users)

If the answer to 2 is NO then:

It is now well established that in some cases outgoing REST calls from IBM-ELM expect a 2-legged OAuth 1.0a flow (the functional equivalent to OIDC’s Client Credential Grant). And it seems that there are different implementations of this: LDX/LQE have allow for separate client keys and secrets, and GCM expects a 2-legged flow using the client keys and secrets from the friend when the oauth_token is blank.

1. Can we have a comprehensive understanding of where and how IBM-ELM uses outgoing 2-legged OAuth 10a flows.

If the answer to 2 is YES then:

              Are the user-ids (as available from the OIDC JWT) available in IBM-ELM for these functional users?

If IBM-ELM can’t sign its outgoing requests with the external OIDC provider, then probably the simplest solution is to continue to require bi-directional OAuth 1.0a. In my view this is the single biggest obstacle to OSLC.

Cheers,

Ed

Ed Gentry
Product Owner

e.gentry@... | +49 0172 8867789 | Per Microsoft Teams anrufen

MID GmbH | Kressengartenstr. 10 | 90402 Nürnberg
Tel.: +49 911 968360 | www.mid.de
Sitz des Unternehmens: Nürnberg Handelsregister: Amtsgericht Nürnberg HRB Nr. 21108
Vorsitzender der Geschäftsführung: Dr. Martin Müller Geschäftsführer: Andreas Ditze
 .