|
Prior to the consolidation of uaa and the login server in uaa release 2.0, we were running our own login server to handle auth to our platform. We simply reduced the instance of the bundled CF login server to 0 and put our own in place, which snagged the login subdomain. This worked just fine; our solution implemented all the needed endpoints to login. We're now upgrading to a newer release with uaa 2.0+ and having difficulties. The uaa registrar hardcodes grabbing the login subdomains: ... - login.<%= properties.domain %> - '*.login.<%= properties.domain %>' ... See: https://github.com/cloudfoundry/cf-release/blob/master/jobs/uaa/templates/cf-registrar.config.yml.erbThis prevents us from taking over login. We locally removed those list items and our custom login server does continue to work. We have some questions about the right approach going forward though. Are uaa and the login server going to continue to merge: to the point where we can no longer take over the login subdomain? Will this strategy no longer be feasible? What's the right answer non ldap/saml environments, if the uaa project's roadmap makes this replacement impossible? If our current solution will continue to work for the foreseeable future, would the uaa team be amenable to a pull-request making the uri values configurable, so we can continue to take over the login subdomain? -Matt Cholick
|
|
|
Hi Matt,
This new wild card route pattern was introduced for multi-tenancy in UAA post merge.
Anything before login or uaa in the URL is now treated as a zone subdomain and the zone context is derived from it.
We will have to look into various approaches to solve this because even if you take over the login subdomain there is possibility for the code to misinterpret the url as a zone specific one.
Let me discuss this with the team and get back to you with possible solutions for the same.
Thanks,
Sree
Sent from my iPad
toggle quoted message
Show quoted text
On May 27, 2015, at 9:58 PM, Matt Cholick <cholick(a)gmail.com> wrote:
Prior to the consolidation of uaa and the login server in uaa release 2.0, we were running our own login server to handle auth to our platform. We simply reduced the instance of the bundled CF login server to 0 and put our own in place, which snagged the login subdomain. This worked just fine; our solution implemented all the needed endpoints to login.
We're now upgrading to a newer release with uaa 2.0+ and having difficulties. The uaa registrar hardcodes grabbing the login subdomains:
...
- login.<%= properties.domain %>
- '*.login.<%= properties.domain %>'
...
See:
https://github.com/cloudfoundry/cf-release/blob/master/jobs/uaa/templates/cf-registrar.config.yml.erb
This prevents us from taking over login. We locally removed those list items and our custom login server does continue to work. We have some questions about the right approach going forward though.
Are uaa and the login server going to continue to merge: to the point where we can no longer take over the login subdomain? Will this strategy no longer be feasible? What's the right answer non ldap/saml environments, if the uaa project's roadmap makes this replacement impossible?
If our current solution will continue to work for the foreseeable future, would the uaa team be amenable to a pull-request making the uri values configurable, so we can continue to take over the login subdomain?
-Matt Cholick
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
hi Sree and Matt, Matt is actually not referring to the wild cards. He wants the login.<domain> for his own application. Matt, at this time we are claiming that domain name, as we did with the login job. We just moved it from one job to another. You may certainly take it out of the cf-registrar script and use it yourself. It is not a configuration that we have tested yet, but I don't foresee that you run into any major challenges. There may be some additional settings that you may have to tinker with https://github.com/cloudfoundry/cf-release/blob/master/jobs/uaa/templates/login.yml.erb#L87-L89You can correspond with Sree, if there is a need for us to completely free up the 'login' sub domain Filip
On Thu, May 28, 2015 at 7:44 AM, Sree Tummidi <stummidi(a)pivotal.io> wrote: Hi Matt,
This new wild card route pattern was introduced for multi-tenancy in UAA
post merge.
Anything before login or uaa in the URL is now treated as a zone subdomain
and the zone context is derived from it.
We will have to look into various approaches to solve this because even if
you take over the login subdomain there is possibility for the code to
misinterpret the url as a zone specific one.
Let me discuss this with the team and get back to you with possible
solutions for the same.
Thanks,
Sree
Sent from my iPad
On May 27, 2015, at 9:58 PM, Matt Cholick <cholick(a)gmail.com> wrote:
Prior to the consolidation of uaa and the login server in uaa release 2.0,
we were running our own login server to handle auth to our platform. We
simply reduced the instance of the bundled CF login server to 0 and put our
own in place, which snagged the login subdomain. This worked just fine; our
solution implemented all the needed endpoints to login.
We're now upgrading to a newer release with uaa 2.0+ and having
difficulties. The uaa registrar hardcodes grabbing the login subdomains:
...
- login.<%= properties.domain %>
- '*.login.<%= properties.domain %>'
...
See:
https://github.com/cloudfoundry/cf-release/blob/master/jobs/uaa/templates/cf-registrar.config.yml.erb
This prevents us from taking over login. We locally removed those list
items and our custom login server does continue to work. We have some
questions about the right approach going forward though.
Are uaa and the login server going to continue to merge: to the point
where we can no longer take over the login subdomain? Will this strategy no
longer be feasible? What's the right answer non ldap/saml environments, if
the uaa project's roadmap makes this replacement impossible?
If our current solution will continue to work for the foreseeable future,
would the uaa team be amenable to a pull-request making the uri values
configurable, so we can continue to take over the login subdomain?
-Matt Cholick
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Bob Brumfield <bob.brumfield@...>
Filip,
When the uaa and login were merged it was state that replacing replacing
the login server would remain a supported scenario and this seems a
departure from that statement. At the very least, its more complex that it
was pre-merge and requires us to modify and issue our own version of
cf-release which we've tried to avoid as much as possible.
Is there some other approach we should be taking here that we're missing?
Thanks,
Bob Brumfield
toggle quoted message
Show quoted text
On Thu, May 28, 2015 at 6:49 AM, Filip Hanik <fhanik(a)pivotal.io> wrote: hi Sree and Matt,
Matt is actually not referring to the wild cards. He wants the
login.<domain> for his own application.
Matt, at this time we are claiming that domain name, as we did with the
login job. We just moved it from one job to another.
You may certainly take it out of the cf-registrar script and use it
yourself. It is not a configuration that we have tested yet, but I don't
foresee that you run into any major challenges.
There may be some additional settings that you may have to tinker with
https://github.com/cloudfoundry/cf-release/blob/master/jobs/uaa/templates/login.yml.erb#L87-L89
You can correspond with Sree, if there is a need for us to completely free
up the 'login' sub domain
Filip
On Thu, May 28, 2015 at 7:44 AM, Sree Tummidi <stummidi(a)pivotal.io> wrote:
Hi Matt,
This new wild card route pattern was introduced for multi-tenancy in UAA
post merge.
Anything before login or uaa in the URL is now treated as a zone
subdomain and the zone context is derived from it.
We will have to look into various approaches to solve this because even
if you take over the login subdomain there is possibility for the code to
misinterpret the url as a zone specific one.
Let me discuss this with the team and get back to you with possible
solutions for the same.
Thanks,
Sree
Sent from my iPad
On May 27, 2015, at 9:58 PM, Matt Cholick <cholick(a)gmail.com> wrote:
Prior to the consolidation of uaa and the login server in uaa release
2.0, we were running our own login server to handle auth to our platform.
We simply reduced the instance of the bundled CF login server to 0 and put
our own in place, which snagged the login subdomain. This worked just fine;
our solution implemented all the needed endpoints to login.
We're now upgrading to a newer release with uaa 2.0+ and having
difficulties. The uaa registrar hardcodes grabbing the login subdomains:
...
- login.<%= properties.domain %>
- '*.login.<%= properties.domain %>'
...
See:
https://github.com/cloudfoundry/cf-release/blob/master/jobs/uaa/templates/cf-registrar.config.yml.erb
This prevents us from taking over login. We locally removed those list
items and our custom login server does continue to work. We have some
questions about the right approach going forward though.
Are uaa and the login server going to continue to merge: to the point
where we can no longer take over the login subdomain? Will this strategy no
longer be feasible? What's the right answer non ldap/saml environments, if
the uaa project's roadmap makes this replacement impossible?
If our current solution will continue to work for the foreseeable future,
would the uaa team be amenable to a pull-request making the uri values
configurable, so we can continue to take over the login subdomain?
-Matt Cholick
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
hi Bob, you can still leverage an outside login server, none of the endpoints to accommodate have changed. We are 100% backwards compatible. I don't believe that we ever stated that we would not use the login.<domain> entry, as we used it with the previous login server. The name was never up for grabs as we weren't even aware that it had been recycled in outside installation. Now, with that being said, I don't think there is an issue with freeing that name up as a configuration option. That's just a matter of a request being made, a story created and implemented. Filip On Thu, May 28, 2015 at 9:33 AM, Bob Brumfield <bob.brumfield(a)gmail.com> wrote: Filip,
When the uaa and login were merged it was state that replacing replacing
the login server would remain a supported scenario and this seems a
departure from that statement. At the very least, its more complex that it
was pre-merge and requires us to modify and issue our own version of
cf-release which we've tried to avoid as much as possible.
Is there some other approach we should be taking here that we're missing?
Thanks,
Bob Brumfield
On Thu, May 28, 2015 at 6:49 AM, Filip Hanik <fhanik(a)pivotal.io> wrote:
hi Sree and Matt,
Matt is actually not referring to the wild cards. He wants the
login.<domain> for his own application.
Matt, at this time we are claiming that domain name, as we did with the
login job. We just moved it from one job to another.
You may certainly take it out of the cf-registrar script and use it
yourself. It is not a configuration that we have tested yet, but I don't
foresee that you run into any major challenges.
There may be some additional settings that you may have to tinker with
https://github.com/cloudfoundry/cf-release/blob/master/jobs/uaa/templates/login.yml.erb#L87-L89
You can correspond with Sree, if there is a need for us to completely
free up the 'login' sub domain
Filip
On Thu, May 28, 2015 at 7:44 AM, Sree Tummidi <stummidi(a)pivotal.io>
wrote:
Hi Matt,
This new wild card route pattern was introduced for multi-tenancy in UAA
post merge.
Anything before login or uaa in the URL is now treated as a zone
subdomain and the zone context is derived from it.
We will have to look into various approaches to solve this because even
if you take over the login subdomain there is possibility for the code to
misinterpret the url as a zone specific one.
Let me discuss this with the team and get back to you with possible
solutions for the same.
Thanks,
Sree
Sent from my iPad
On May 27, 2015, at 9:58 PM, Matt Cholick <cholick(a)gmail.com> wrote:
Prior to the consolidation of uaa and the login server in uaa release
2.0, we were running our own login server to handle auth to our platform.
We simply reduced the instance of the bundled CF login server to 0 and put
our own in place, which snagged the login subdomain. This worked just fine;
our solution implemented all the needed endpoints to login.
We're now upgrading to a newer release with uaa 2.0+ and having
difficulties. The uaa registrar hardcodes grabbing the login subdomains:
...
- login.<%= properties.domain %>
- '*.login.<%= properties.domain %>'
...
See:
https://github.com/cloudfoundry/cf-release/blob/master/jobs/uaa/templates/cf-registrar.config.yml.erb
This prevents us from taking over login. We locally removed those list
items and our custom login server does continue to work. We have some
questions about the right approach going forward though.
Are uaa and the login server going to continue to merge: to the point
where we can no longer take over the login subdomain? Will this strategy no
longer be feasible? What's the right answer non ldap/saml environments, if
the uaa project's roadmap makes this replacement impossible?
If our current solution will continue to work for the foreseeable
future, would the uaa team be amenable to a pull-request making the uri
values configurable, so we can continue to take over the login subdomain?
-Matt Cholick
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
toggle quoted message
Show quoted text
On Thu, May 28, 2015 at 8:38 AM, Filip Hanik <fhanik(a)pivotal.io> wrote: hi Bob, you can still leverage an outside login server, none of the
endpoints to accommodate have changed. We are 100% backwards compatible. I
don't believe that we ever stated that we would not use the login.<domain>
entry, as we used it with the previous login server. The name was never up
for grabs as we weren't even aware that it had been recycled in outside
installation.
Now, with that being said, I don't think there is an issue with freeing
that name up as a configuration option. That's just a matter of a request
being made, a story created and implemented.
Filip
On Thu, May 28, 2015 at 9:33 AM, Bob Brumfield <bob.brumfield(a)gmail.com>
wrote:
Filip,
When the uaa and login were merged it was state that replacing replacing
the login server would remain a supported scenario and this seems a
departure from that statement. At the very least, its more complex that it
was pre-merge and requires us to modify and issue our own version of
cf-release which we've tried to avoid as much as possible.
Is there some other approach we should be taking here that we're missing?
Thanks,
Bob Brumfield
On Thu, May 28, 2015 at 6:49 AM, Filip Hanik <fhanik(a)pivotal.io> wrote:
hi Sree and Matt,
Matt is actually not referring to the wild cards. He wants the
login.<domain> for his own application.
Matt, at this time we are claiming that domain name, as we did with the
login job. We just moved it from one job to another.
You may certainly take it out of the cf-registrar script and use it
yourself. It is not a configuration that we have tested yet, but I don't
foresee that you run into any major challenges.
There may be some additional settings that you may have to tinker with
https://github.com/cloudfoundry/cf-release/blob/master/jobs/uaa/templates/login.yml.erb#L87-L89
You can correspond with Sree, if there is a need for us to completely
free up the 'login' sub domain
Filip
On Thu, May 28, 2015 at 7:44 AM, Sree Tummidi <stummidi(a)pivotal.io>
wrote:
Hi Matt,
This new wild card route pattern was introduced for multi-tenancy in
UAA post merge.
Anything before login or uaa in the URL is now treated as a zone
subdomain and the zone context is derived from it.
We will have to look into various approaches to solve this because even
if you take over the login subdomain there is possibility for the code to
misinterpret the url as a zone specific one.
Let me discuss this with the team and get back to you with possible
solutions for the same.
Thanks,
Sree
Sent from my iPad
On May 27, 2015, at 9:58 PM, Matt Cholick <cholick(a)gmail.com> wrote:
Prior to the consolidation of uaa and the login server in uaa release
2.0, we were running our own login server to handle auth to our platform.
We simply reduced the instance of the bundled CF login server to 0 and put
our own in place, which snagged the login subdomain. This worked just fine;
our solution implemented all the needed endpoints to login.
We're now upgrading to a newer release with uaa 2.0+ and having
difficulties. The uaa registrar hardcodes grabbing the login subdomains:
...
- login.<%= properties.domain %>
- '*.login.<%= properties.domain %>'
...
See:
https://github.com/cloudfoundry/cf-release/blob/master/jobs/uaa/templates/cf-registrar.config.yml.erb
This prevents us from taking over login. We locally removed those list
items and our custom login server does continue to work. We have some
questions about the right approach going forward though.
Are uaa and the login server going to continue to merge: to the point
where we can no longer take over the login subdomain? Will this strategy no
longer be feasible? What's the right answer non ldap/saml environments, if
the uaa project's roadmap makes this replacement impossible?
If our current solution will continue to work for the foreseeable
future, would the uaa team be amenable to a pull-request making the uri
values configurable, so we can continue to take over the login subdomain?
-Matt Cholick
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
