Given your comment <quote> 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. </quote> If you continue down the “websso” as resource path you might end up with the URL below which makes little sense to me at this point. https://localhost:8443/gateway/auth-rest/knoxsso/api/v1/websso This says to me that topology deployed specifically for REST API authentication federation has a service with a resource for WebSSO flows for browsers/cookies. Right?
On 11/3/15, 7:36 AM, "larry mccay" <[email protected]> wrote: >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 >>
