Okay...
In the near term, I think that we should use the existing topology
descriptor approach and limit Knoxsso to a single configuration per
deployment.
In many deployment scenarios - especially those managed by Ambari there is
only one cluster anyway.
We should start to consider a different
Agreed.
I'm not sure that you would name your topology that way if you intended to
use it for REST though.
We could certainly create credential collectors in the client shell that
interacted with a HTTP basic auth fronted websso service and manages the
returned cookies in a protected file. Like a
Perhaps returning to the elimination of the service component within the
resource path makes sense after all:
https://localhost:8443/gateway/knoxsso/api/v1/websso
Out of the box the knoxsso.xml topology can be configured for SAML as a
starting point but can be changed to whatever makes sense.
These don’t seem terrible to me but I question if they are actually what you
meant.
https://localhost:8443/gateway/sandbox/auth-ui/knoxsso/api/v1/websso
https://localhost:8443/gateway/sandbox/auth-rest/knoxsso/api/v1/websso
Can you clarify in terms of {gateway}/{topology}/{service}/{resource}
