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