Re: Authentication for OSLC Link Profile

François-Régis Jaunatre <frjaunatre@...>

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.

Best regards, Sincères salutations,

François-Régis Jaunatre
OSLC Connect for Windchill & OSLC Lab

Check out OSLC Connect for Jira & OSLC Connect for Windchill


From: oslc-op@... <oslc-op@...> On Behalf Of Gentry, Edward via
Sent: 28 September 2022 10:21
To: Jim Amsden <jamsden@...>; oslc-op@...; Eran Gery <eran.gery@...>; David Honey2 <david.honey@...>
Subject: [oslc-op] Authentication for OSLC Link Profile


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.






Ed Gentry
Product Owner

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



MID GmbH | Kressengartenstr. 10 | 90402 Nürnberg
Tel.: +49 911 968360 |
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


Join { to automatically receive all group messages.