[DISCUSSION] WebSSO Service Resource Path

[larry mccay]

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

Re: [DISCUSSION] WebSSO Service Resource Path

[Kevin Minder]

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

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






On 11/2/15, 1:34 PM, "larry mccay"  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

Re: [DISCUSSION] WebSSO Service Resource Path

[larry mccay]

inline...


On Mon, Nov 2, 2015 at 11:31 PM, Kevin Minder 
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"  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
>

Re: [DISCUSSION] WebSSO Service Resource Path

[Kevin Minder]

Given your comment

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.

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"  wrote:

>inline...
>
>
>On Mon, Nov 2, 2015 at 11:31 PM, Kevin Minder 
>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"  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
>>

Re: [DISCUSSION] WebSSO Service Resource Path

[larry mccay]

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/
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-saml/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 
wrote:

> Given your comment
> 
> 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.
> 
> 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"  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"  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

Re: [DISCUSSION] WebSSO Service Resource Path

[larry mccay]

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  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/
> 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-saml/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  > wrote:
>
>> Given your comment
>> 
>> 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.
>> 
>> 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"  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
>> >> htt

Re: [DISCUSSION] WebSSO Service Resource Path

[Kevin Minder]

Inline...



On 11/3/15, 11:39 AM, "larry mccay"  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  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/
>> 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-saml/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 > > wrote:
>>
>>> Given your comment
>>> 
>>> 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.
>>> 
>>> 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"  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 ge

Re: [DISCUSSION] WebSSO Service Resource Path

[larry mccay]

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/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 
wrote:

> Inline...
>
>
>
> On 11/3/15, 11:39 AM, "larry mccay"  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 
> 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/
> >> 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-saml/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

Re: [DISCUSSION] WebSSO Service Resource Path

[larry mccay]

Okay...

In the near term, I think that we should use the existing topology
descriptor approach and limit Knoxsso to a single configuration per
deployment.
In many deployment scenarios - especially those managed by Ambari there is
only one cluster anyway.

We should start to consider a different approach for deploying services
that are part of the gateway itself that are cross cluster, etc.
Backward compatibility would need to be maintained for the near term
topologies when they are encountered in the future but a migration path to
a more comprehensive approach would be available as well.


On Tue, Nov 3, 2015 at 2:00 PM, larry mccay  wrote:

> 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/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 <
> kevin.min...@hortonworks.com> wrote:
>
>> Inline...
>>
>>
>>
>> On 11/3/15, 11:39 AM, "larry mccay"  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 
>> 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/
>> >> 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 i