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