Re: Authentication for OSLC Link Profile

Gentry, Edward

Hi François-Régis,


Yes OAuth 1.0a would be the fall back position. But if ELM supports OIDC bi-directionally as I’ve described then we can finally leave 1.0a in the dust bin.


I had a talk with the IBM team a month ago and there heard language that might indicate that ELM might sign outgoing requests with OIDC tokens. It was not convenient, at that time, to explore it further, and to determine if it was true and these were token from the external authentication provider and not just JAS/Liberty.


My point is that if we have the opportunity to free ourselves from 1.0a shackles we should do it.


Otherwise, then exactly as you suggest.






From: François-Régis Jaunatre <frjaunatre@...>
Sent: Mittwoch, 28. September 2022 11:44
To: oslc-op@...; Gentry, Edward <e.gentry@...>; Jim Amsden <jamsden@...>; Eran Gery <eran.gery@...>; David Honey2 <david.honey@...>
Subject: RE: [oslc-op] Authentication for OSLC Link Profile


Sie erhalten nicht oft eine E-Mail von frjaunatre@.... Erfahren Sie, warum dies wichtig ist

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.