Authentication for OSLC Link Profile
Gentry, Edward
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
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.
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
e.gentry@... | +49 0172 8867789 | Per Microsoft Teams anrufen
MID GmbH | Kressengartenstr. 10 | 90402 Nürnberg
|
|