Sorry for the slow response.

Thanks Dmitriy for the outline of the read-only access.

Additional "admin" access probably wasn't a good way to describe what I was
referring to. Below is a description of an approach that I think could be a
very powerful target state and help with many of the challenges we’ve been
facing. I can only assume it is a bit more than you were looking for in the
context of introducing the UAA into BOSH. It obviously requires changes to
BOSH beyond integration of the UAA.

I think the proposed roles (and corresponding scopes) of full admin, which
can be thought of as “root” for the Director, and full read-only make sense
as is. The other roles I would propose would require providing an option to
externalize credentials and other sensitive information from deployment
manifests.

- Secrets Manager

Manifests generally contain a lot of sensitive information and basically
give you full access to a deployment. In regulated and security sensitive
environments, identity and secrets management can be a dedicated
function/role. It would be beneficial to provide an option to use a syntax
in manifests to reference external “secrets” so that the deployment manifest
need not contain any sensitive information. The secrets would be sourced
into the manifest when BOSH requires them. Either BOSH itself would provide
the secrets management or, optimally, a pluggable mechanism could be
provided to retrieve them from a dedicated secrets management solution (e.g.
something like Hashicorp Vault).

The secrets management capability, if native to the platform, could also be
leveraged by release authors so that sensitive information does not need to
be written to the filesystem of the BOSH VMs but rather dynamically fetched
when a job starts or when needed.

For those not interested in externalizing secrets from manifests, the
existing approach would continue to work.

- Deployer

A deployer is the role that is permitted to introduce change into the
environment. It is similar to the
'bosh.<DIRECTOR-UUID>.deployments-tag.<TAG>.admin’ already proposed scope.
They can modify specific deployments that exist and new deployments. To
adhere to least privilege, if a deployment externalizes secrets as outlined
above, the deployer preferably would not be able to access those
credentials. Deployers should not need nor require access to the deployed
system (e.g. bosh ssh).

- Deployment Support

For lack of a better description, I refer to the last role as deployment
support. The support role has the ability to access the running systems or
access an operations that would be used to support the environment. Beyond
the capabilities of the read-only role, this would include operations such
as:
* ssh/scp
* cloudcheck
* logs
* recreate/start/stop/restart job

A concrete use case for this role follow. In many environments, persistent
access to production systems is not permitted. Access to production systems
should only be allowed when there is some type of incident ticket or change
ticket registered. When a ticket is registered, an external system could
dynamically assign a “bosh.<director-uuid>.deployments-tag.<tag>.support”
scope to the appropriate user(s) in the UAA (or a backing store of the UAA
such as LDAP). When the ticket is closed that scope would be revoked
(assumes token expiry is set to a sufficiently short period since I don’t
believe there is token invalidation in the UAA).

Hopefully this makes some sense. I can provide some additional use cases
around the roles if it helps.



--
View this message in context: http://cf-bosh.70367.x6.nabble.com/cf-bosh-Resuming-UAA-work-tp75p207.html
Sent from the CF BOSH mailing list archive at Nabble.com.

I've updated https://github.com/cloudfoundry/bosh-notes/blob/master/uaa.md
to list out planned viewable resources by read-only users.

By far the biggest authorization requirement we get from our security

teams is being able to provide a level of "admin" access that can perform
most functions but can't access credentials and sensitive information.

What kind of "admin" access do you think should be provided?





On Wed, Jun 3, 2015 at 8:07 AM, dehringer <david.ehringer(a)gmail.com> wrote:

What are some of the functions that a read-only user scope would be able to
perform. I really like the idea of a read-only scope but it seems like
today
there are only a few functions that aren't intended to modify the state of
the system or indirectly can allow for modification of the system (e.g.
bosh
ssh/scp).

By far the biggest authorization requirement we get from our security teams
is being able to provide a level of "admin" access that can perform most
functions but can't access credentials and sensitive information. Simply
hooking in UAA obviously doesn't help with this as this is deeply related
to
how deployment manifests work in general. But I mention it because this is
the type of authorization and access control requirements our security
teams
are providing.



--
View this message in context:
http://cf-bosh.70367.x6.nabble.com/cf-bosh-Resuming-UAA-work-tp75p116.html
Sent from the CF BOSH mailing list archive at Nabble.com.
_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh

What are some of the functions that a read-only user scope would be able to
perform. I really like the idea of a read-only scope but it seems like today
there are only a few functions that aren't intended to modify the state of
the system or indirectly can allow for modification of the system (e.g. bosh
ssh/scp).

By far the biggest authorization requirement we get from our security teams
is being able to provide a level of "admin" access that can perform most
functions but can't access credentials and sensitive information. Simply
hooking in UAA obviously doesn't help with this as this is deeply related to
how deployment manifests work in general. But I mention it because this is
the type of authorization and access control requirements our security teams
are providing.



--
View this message in context: http://cf-bosh.70367.x6.nabble.com/cf-bosh-Resuming-UAA-work-tp75p116.html
Sent from the CF BOSH mailing list archive at Nabble.com.

cool, thanks Gwenn!

Alberto Flores
http://www.linkedin.com/in/aflores

“A war against standards leads logically and inevitably to hostility to
religion, because it is religious faith that provides the ultimate basis
for all standards.” - Michael Medved

"(T)he foundation of our national policy will be laid in the pure and
immutable principles of private morality; ...the propitious smiles of
Heaven can never be expected on a nation that disregards the eternal rules
of order and right which Heaven itself has ordained..." George Washington,
First Inaugural, April 30 1789



On Fri, May 29, 2015 at 6:22 AM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

Yes should be ok.

By the way the best way to use the Uaa is by the provided api.

thanks

On Fri, May 29, 2015 at 7:16 PM, Alberto A. Flores <aaflores(a)gmail.com>
wrote:

Thanks Gween,

so just to be clear, I should be able to install UAA standalone and the
cf-uaac to interact with it. No need to install CloudFoundry.

Alberto Flores
http://www.linkedin.com/in/aflores

“A war against standards leads logically and inevitably to hostility to
religion, because it is religious faith that provides the ultimate basis
for all standards.” - Michael Medved

"(T)he foundation of our national policy will be laid in the pure and
immutable principles of private morality; ...the propitious smiles of
Heaven can never be expected on a nation that disregards the eternal rules
of order and right which Heaven itself has ordained..." George
Washington, First Inaugural, April 30 1789



On Fri, May 29, 2015 at 5:55 AM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

https://github.com/cloudfoundry/cf-uaac Is a ruby client and should be
able to help you, even if the name is "cf-"

I think even if uaac is not really cloudfoundry this mailling list is ok.


On Fri, May 29, 2015 at 6:22 PM, Alberto A. Flores <aaflores(a)gmail.com>
wrote:

Filip,

Does the uaa have a cli? It seems like uaac is a "cloudfoundry" thing.
Sound like cli interactions are expected through curl.

PS: wasn't sure where to ask this question since the UAA is a project
of it's own. Maybe it's too early to have a mailing list for it. Do you
inow where we can post questions for it? Cf mailing list?

Alberto
Twitter: albertoaflores

On May 28, 2015, at 6:53 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

The UAA doesn't depend on CF, it can be leveraged as a stand alone
product.


On Thu, May 28, 2015 at 4:52 PM, Aristoteles Neto <
aristoteles.neto(a)webdrive.co.nz> wrote:

From the perspective of using BOSH without CF, moving the users to the
manifest is actually an improvement, as it allows you to list the actual
users without logging in to the DB.

Are there any plans to split out UAA from Cloud Foundry? More
specifically I’d love to be able to have groups / permissions scheme for
deployments / commands without needing to install CF.

-- Neto



On 29/05/2015, at 10:33, 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


_______________________________________________
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

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

Yes should be ok.

By the way the best way to use the Uaa is by the provided api.

thanks

On Fri, May 29, 2015 at 7:16 PM, Alberto A. Flores <aaflores(a)gmail.com>
wrote:

Thanks Gween,

so just to be clear, I should be able to install UAA standalone and the
cf-uaac to interact with it. No need to install CloudFoundry.

Alberto Flores
http://www.linkedin.com/in/aflores

“A war against standards leads logically and inevitably to hostility to
religion, because it is religious faith that provides the ultimate basis
for all standards.” - Michael Medved

"(T)he foundation of our national policy will be laid in the pure and
immutable principles of private morality; ...the propitious smiles of
Heaven can never be expected on a nation that disregards the eternal rules
of order and right which Heaven itself has ordained..." George Washington,
First Inaugural, April 30 1789



On Fri, May 29, 2015 at 5:55 AM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

https://github.com/cloudfoundry/cf-uaac Is a ruby client and should be
able to help you, even if the name is "cf-"

I think even if uaac is not really cloudfoundry this mailling list is ok.


On Fri, May 29, 2015 at 6:22 PM, Alberto A. Flores <aaflores(a)gmail.com>
wrote:

Filip,

Does the uaa have a cli? It seems like uaac is a "cloudfoundry" thing.
Sound like cli interactions are expected through curl.

PS: wasn't sure where to ask this question since the UAA is a project of
it's own. Maybe it's too early to have a mailing list for it. Do you inow
where we can post questions for it? Cf mailing list?

Alberto
Twitter: albertoaflores

On May 28, 2015, at 6:53 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

The UAA doesn't depend on CF, it can be leveraged as a stand alone
product.


On Thu, May 28, 2015 at 4:52 PM, Aristoteles Neto <
aristoteles.neto(a)webdrive.co.nz> wrote:

From the perspective of using BOSH without CF, moving the users to the
manifest is actually an improvement, as it allows you to list the actual
users without logging in to the DB.

Are there any plans to split out UAA from Cloud Foundry? More
specifically I’d love to be able to have groups / permissions scheme for
deployments / commands without needing to install CF.

-- Neto



On 29/05/2015, at 10:33, 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


_______________________________________________
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

Thanks Gween,

so just to be clear, I should be able to install UAA standalone and the
cf-uaac to interact with it. No need to install CloudFoundry.

Alberto Flores
http://www.linkedin.com/in/aflores

“A war against standards leads logically and inevitably to hostility to
religion, because it is religious faith that provides the ultimate basis
for all standards.” - Michael Medved

"(T)he foundation of our national policy will be laid in the pure and
immutable principles of private morality; ...the propitious smiles of
Heaven can never be expected on a nation that disregards the eternal rules
of order and right which Heaven itself has ordained..." George Washington,
First Inaugural, April 30 1789



On Fri, May 29, 2015 at 5:55 AM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

https://github.com/cloudfoundry/cf-uaac Is a ruby client and should be
able to help you, even if the name is "cf-"

I think even if uaac is not really cloudfoundry this mailling list is ok.


On Fri, May 29, 2015 at 6:22 PM, Alberto A. Flores <aaflores(a)gmail.com>
wrote:

Filip,

Does the uaa have a cli? It seems like uaac is a "cloudfoundry" thing.
Sound like cli interactions are expected through curl.

PS: wasn't sure where to ask this question since the UAA is a project of
it's own. Maybe it's too early to have a mailing list for it. Do you inow
where we can post questions for it? Cf mailing list?

Alberto
Twitter: albertoaflores

On May 28, 2015, at 6:53 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

The UAA doesn't depend on CF, it can be leveraged as a stand alone
product.


On Thu, May 28, 2015 at 4:52 PM, Aristoteles Neto <
aristoteles.neto(a)webdrive.co.nz> wrote:

From the perspective of using BOSH without CF, moving the users to the
manifest is actually an improvement, as it allows you to list the actual
users without logging in to the DB.

Are there any plans to split out UAA from Cloud Foundry? More
specifically I’d love to be able to have groups / permissions scheme for
deployments / commands without needing to install CF.

-- Neto



On 29/05/2015, at 10:33, 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


_______________________________________________
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

https://github.com/cloudfoundry/cf-uaac Is a ruby client and should be able
to help you, even if the name is "cf-"

I think even if uaac is not really cloudfoundry this mailling list is ok.


On Fri, May 29, 2015 at 6:22 PM, Alberto A. Flores <aaflores(a)gmail.com>
wrote:

Filip,

Does the uaa have a cli? It seems like uaac is a "cloudfoundry" thing.
Sound like cli interactions are expected through curl.

PS: wasn't sure where to ask this question since the UAA is a project of
it's own. Maybe it's too early to have a mailing list for it. Do you inow
where we can post questions for it? Cf mailing list?

Alberto
Twitter: albertoaflores

On May 28, 2015, at 6:53 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

The UAA doesn't depend on CF, it can be leveraged as a stand alone product.


On Thu, May 28, 2015 at 4:52 PM, Aristoteles Neto <
aristoteles.neto(a)webdrive.co.nz> wrote:

From the perspective of using BOSH without CF, moving the users to the
manifest is actually an improvement, as it allows you to list the actual
users without logging in to the DB.

Are there any plans to split out UAA from Cloud Foundry? More
specifically I’d love to be able to have groups / permissions scheme for
deployments / commands without needing to install CF.

-- Neto



On 29/05/2015, at 10:33, 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


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

Filip,

Does the uaa have a cli? It seems like uaac is a "cloudfoundry" thing. Sound like cli interactions are expected through curl.

PS: wasn't sure where to ask this question since the UAA is a project of it's own. Maybe it's too early to have a mailing list for it. Do you inow where we can post questions for it? Cf mailing list?

Alberto
Twitter: albertoaflores

Thanks Dmitriy!

Alberto
Twitter: albertoaflores

Sure feel free to leave comments on the issue (
https://github.com/cloudfoundry/bosh-notes/issues/8) or file a PR against
that document and I will try to incorporate it.

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

Thanks for the response!

+1 on the "bosh-director.DIRECTOR-UUID.admin" scope. I assume this means
that in the event of multiple directors, users will have to have multiple
scopes associated to their credentials (either through uaa or local). That
would be a great start.

Is there anyway i can follow/vote on the items regarding authz? I like the
proposed scope schemes to create some ACL control. I'm hoping to use BOSH
as a viable tool to empower datacenter operators. As this is defined, the
idea or different roles is essential. (Are pull request welcomed?)

Alberto
Twitter: albertoaflores

On May 28, 2015, at 7:20 PM, Dmitriy Kalinin <dkalinin(a)pivotal.io>

wrote:

bosh-director.DIRECTOR-UUID.admin

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

Thanks for the response!

+1 on the "bosh-director.DIRECTOR-UUID.admin" scope. I assume this means that in the event of multiple directors, users will have to have multiple scopes associated to their credentials (either through uaa or local). That would be a great start.

Is there anyway i can follow/vote on the items regarding authz? I like the proposed scope schemes to create some ACL control. I'm hoping to use BOSH as a viable tool to empower datacenter operators. As this is defined, the idea or different roles is essential. (Are pull request welcomed?)

Alberto
Twitter: albertoaflores

I've added a bosh-notes page about UAA integration:
https://github.com/cloudfoundry/bosh-notes/blob/master/uaa.md (and
associated issue: https://github.com/cloudfoundry/bosh-notes/issues/8)

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

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

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

Love it!

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

Alberto
Twitter: albertoaflores

True - silly me.

Sounds great :)

-- Neto

The UAA doesn't depend on CF, it can be leveraged as a stand alone product.


On Thu, May 28, 2015 at 4:52 PM, Aristoteles Neto <
aristoteles.neto(a)webdrive.co.nz> wrote:

From the perspective of using BOSH without CF, moving the users to the
manifest is actually an improvement, as it allows you to list the actual
users without logging in to the DB.

Are there any plans to split out UAA from Cloud Foundry? More specifically
I’d love to be able to have groups / permissions scheme for deployments /
commands without needing to install CF.

-- Neto



On 29/05/2015, at 10:33, 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

From the perspective of using BOSH without CF, moving the users to the manifest is actually an improvement, as it allows you to list the actual users without logging in to the DB.

Are there any plans to split out UAA from Cloud Foundry? More specifically I’d love to be able to have groups / permissions scheme for deployments / commands without needing to install CF.

-- Neto

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

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