inline...
On Mon, Nov 2, 2015 at 11:31 PM, Kevin Minder <[email protected]> wrote: > 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 Oh, you're right - sandbox shouldn't have been in there. https://localhost:8443/gateway/auth-ui/knoxsso/api/v1/websso Topology name represents something about the SSO mechanism - either the target users "ui" or maybe the auth method "basic" vs "saml", etc. Knoxsso would be the service component. Resource would be api/v1/websso - though whether the service is part of the resource path can be debated. > > 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 > > Interesting question... I assumed that the resource name would differentiate between the types of tokens returned. So, "websso" for WebSSO flows for browsers/cookies and maybe "token" or something for REST clients - like OAuth. One will set a cookie as a result the other return JSON with a token to use as bearer token and metadata about the token. > > > > > > On 11/2/15, 1:34 PM, "larry mccay" <[email protected]> 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 >
