Good point... So, we couldn't have admin and knoxsso APIs in the same topology. We could have other fully qualified services/URLs in the same topology though - like WEBHDFS.
This starts to feel like maybe this is a misuse of topologies and that we really need to be able to colocate them with some additional context and metadata. Since topologies are - at least originally - intended to represent multiple clusters, we would need to somehow have admin (maybe not) and knoxsso topologies for each cluster topology. Which becomes a namespace/URL problem since only the topology name is in the URL now. Maybe something else for cross cutting concern APIs across all the topologies and gateway instances needs to be defined. *https://localhost:8443/gateway/services/knoxsso/api/v1/websso <https://localhost:8443/gateway/services/knoxsso/api/v1/websso>* *https://localhost:8443/gateway/services/admin/api/v1/topologies <https://localhost:8443/gateway/services/admin/api/v1/topologies>* This provides us with a way to expose gateway services separately from hadoop cluster services. However, if we are to colocate them in the same descriptor then we will need a way to define provider chains per service. Conversely, if we added a new directory in conf/topologies for conf/topologies/gateway then we could aggregate them all under services but provision their own provider chains. On Tue, Nov 3, 2015 at 11:47 AM, Kevin Minder <[email protected]> wrote: > Inline... > > > > On 11/3/15, 11:39 AM, "larry mccay" <[email protected]> wrote: > > >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? > > This isn’t really new as I believe we already do this in the admin > topology. The thing that needs to be understood here is that the "service" > component of the URL is really “api" in this case and the resource > component “v1/websso”. So the assumption is that this service will never > be used in a topology with other services since the service unique > component of the URL “api” isn’t very unique or descriptive. > > The broader question is should there be specialized support in the > framework for these single service topologies to somehow enforce this > assumption and therefore make this naming decision easier. We have > struggled with it both times we’ve encountered it. Note that in both cases > we were hosting services within Knox and not routing to external services > so this may be the “norm” here. > > > > > > >On Tue, Nov 3, 2015 at 9:49 AM, larry mccay <[email protected]> > 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 < > [email protected] > >> > 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" <[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 > >>> >> > >>> > >> > >> >
