We will ask the UAA team to start producing uaa-release shortly, which
will be independent of cf-release. Eventually I expect people will remove
uaa job from cf-release and just use uaa-release.

Regarding scope: Our first goal is to allow to use one scope to determine
who can interact with the Director as an admin. We have not decided yet
whether we should make it configurable or something that is implied. Two
options:
- Director manifest says `admin_scope: some-scope-in-uaa`
- Director assumes `bosh-director.DIRECTOR-UUID.admin` scope gives admin
access

Regarding authz: Eventually we will introduce readonly user scope
(bosh-director.DIRECTOR-UUID.read-only), and after that we will introduce
deployment specific scopes (e.g.
bosh-director.DIRECTOR-UUID.deployment.DEPLOYMENT.admin/read-only). This
work is not scoped out yet.

Thoughts on the scope conventions?

On Thu, May 28, 2015 at 3:57 PM, Alberto A. Flores <aaflores(a)gmail.com>
wrote:

Love it!

I'm wondering what are your thoughts for authorization? Wondering if the
Director will introduce roles of any kind...

Alberto
Twitter: albertoaflores

On May 28, 2015, at 6:49 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Sounds great! I assume you'll use a uaa oauth scope to determine if the
given user actually has access to bosh? bosh.admin?

On Thu, May 28, 2015 at 4:33 PM, Dmitriy Kalinin <dkalinin(a)pivotal.io>
wrote:

Hey all,

We have resumed BOSH & UAA integration work:
https://www.pivotaltracker.com/n/projects/1285490 to be worked on by a
single pair.

As part of this work we are going to provide two options how to
configure the Director auth:
- without UAA [default] (already exists, but we want to simplify it)
- with UAA (currently being worked on)

Currently Director only works without UAA and has its own user
management functionality. There is the users table in the DB and CLI
provides create/delete user commands. I would like to simplify this
functionality as much as possible. Users would be configured statically in
the manifest for the Director so that we can delete users table and
associated commands.

Here is how the Director manifest would look like for 'Director without
UAA' configuration:

properties:
director:
users:
- {name: admin, hashed_password: $1$0497b6da$8/0owfq5zblA3o7kXQgGy}
# crypted 'password'
- {name: admin2, hashed_password: $1$0497b6da$8/0owfq5zblA3o7kXQgGy}
# crypted 'password'
...

For more complex use cases, we will encourage people to use Director
auth via UAA once that becomes available so that LDAP, password, lockout
policies, etc. can be configured.

Thoughts?

Dmitriy

_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh

_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh


_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh