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. Knoxsso will still make sense as a topology name and websso will still represent cookie based tokens for browser-like clients. If additional authentication configurations are needed then we can add more specific topology names - such as: https://localhost:8443/gateway/oauth/api/v1/websso I guess this thread just came back around full circle and my original thoughts are making sense again. :) We should however agree or not as to whether we want to break the existing pattern for all services to have topology and service components represented in their URLs. I will propose that we allow this - thoughts? On Tue, Nov 3, 2015 at 9:49 AM, larry mccay <larry.mc...@gmail.com> wrote: > 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 command line cookie-jar. I > actually think this is a pretty good idea though you could do the same with > JSON instead. > > https://localhost:8443/gateway/auth-rest/knoxsso/api/v1/ > <https://localhost:8443/gateway/auth-rest/knoxsso/api/v1/websso>cookie > might be more accurate but it doesn't illustrate the redirect implications > of websso flows. Maybe that isn't as intuitive to everyone with websso > either but that is the intent. > > The following may be more intuitive: > https://localhost:8443/gateway/auth-basic/knoxsso/api/v1/websso > <https://localhost:8443/gateway/auth-rest/knoxsso/api/v1/websso> > https://localhost:8443/gateway/auth-saml/knoxsso/api/v1/websso > <https://localhost:8443/gateway/auth-rest/knoxsso/api/v1/websso> > > Now, auth-basic implies HTTP basic auth but websso implies redirect websso > flows. :/ > The intent is to use auth-basic to get a cookie to be managed by browsers > (or browser-like clients) for WebSSO. > > If we were to provide an sso topology out of the box what would we want to > call it then? > > I would think that the most common real SSO mechanism for WebSSO in an > enterprise would be SAML. > We could call it auth-saml out of the box but as soon as they want to > change it to use HTTP basic against LDAP or something else the name is no > longer representative. > > Which is how I got to auth-web... > > May be over thinking the whole thing but naming is hard for these sorts of > things. > > > On Tue, Nov 3, 2015 at 9:21 AM, Kevin Minder <kevin.min...@hortonworks.com > > wrote: > >> 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" <lmc...@apache.org> wrote: >> >> >inline... >> > >> > >> >On Mon, Nov 2, 2015 at 11:31 PM, Kevin Minder < >> kevin.min...@hortonworks.com> >> >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" <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 >> >> >> > >
