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} how that
is built?
Just for background, I usually think about the URLs getting built like this.
For example, is it like this?
gateway=https://localhost:8443/gateway
topology=sandbox
service=auth-ui
resource=knoxsso/api/v1/websso
Or are you really thinking this where auth-ui and auth-rest are the service
components?
https://localhost:8443/gateway/auth-ui/knoxsso/api/v1/websso
https://localhost:8443/gateway/auth-rest/knoxsso/api/v1/websso
And if the resource really does token exchange why not
https://localhost:8443/gateway/auth-ui/knoxsso/api/v1/token-exchange
https://localhost:8443/gateway/auth-rest/knoxsso/api/v1/token-exchange
On 11/2/15, 1:34 PM, "larry mccay" <lmc...@apache.org> wrote:
>All -
>
>I am considering the option of removing the topology "service" name from
>the API resource path.
>
>The current implementation is aligned with all existing patterns for
>service integrations but seems to pose a more difficult time in naming the
>topology than it should.
>
>Considering that the current service name is knoxsso that is then further
>qualified with websso - we have a topology naming issue.
>
>We have considered things like idp.xml which would result in:
>
>https://localhost:8443/gateway/sandbox/idp/knoxsso/api/v1/websso
>
>This sort of works but idp isn't really accurate in that this is a
>federation provider that facilitates token exchange with various SSO
>provider integrations.
>
>Moreover, the service name seems to call out the behavior and if it truly
>is facilitating *the* single sign on integration for an enterprise then it
>is redundant.
>
>So, the initial thought was to eliminate the use of a specific service name
>within the resource path and just name the topology appropriately. More
>like:
>
>https://localhost:8443/gateway/sandbox/knoxsso/api/v1/websso
>
>If there is only one then this makes a lot of sense.
>
>However, if we need to provide another version of SSO for say REST APIs
>where cookies may not be used then we will need to either accommodate both
>in the same knoxsso.xml topology or deploy another with different
>federation capabilities. For instance:
>
>https://localhost:8443/gateway/sandbox/knoxsso-rest/api/v1/websso
>
>This seems to hold together but also strikes me odd that both of these "top
>level services" (meaning no service name?) have the same API.
>
>I guess the question is whether we want to be strict about resource naming
>here? It seems that simplifying it this way might make the actual resource
>- which is a token exchange mechanism - be ambiguous which feels wrong.
>
>If this is wrong then we go back to having the topology naming to wrestle
>with. Perhaps the following isn't so bad:
>
>https://localhost:8443/gateway/sandbox/auth-ui/knoxsso/api/v1/websso
>https://localhost:8443/gateway/sandbox/auth-rest/knoxsso/api/v1/websso
>
>Thoughts?
>
>thanks,
>
>--larry
