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 > >> >
