Hi David, I'd like to use gbean permissions. Gbean permission would be tied to the codebase and gbean name (so it's not tied to authenticated subject). Protected resource would be alias name, and action would be read.
For vault administration I can do subject-based authorization check. At deployment time (or later) policy statement must be defined that grants access to the alias for the specific gbean. Hopefully we can have some reasonable defaults. Even if somebody wants to encrypt all their secrets before they are included into the plan, they still need a vault to save encryption key. Hopefully it would be not too complicated to work with... I was thinking about login into the vault but it does not seem to fit very well here. Simon On Nov 20, 2005, at 11:59 PM, [EMAIL PROTECTED] wrote: >This seems like a good idea to me, but I'm missing a lot of the picture >about how it will work and what else is needed. >Lets take a db pool as an example, with a username/password to get the >connections. We store the password in the safe. So, when the db pool >gbean (connection manager) starts, it needs to access the safe to get >the password. How does the safe trust the gbean? The only way I can >see is if the server is started as some kind of admin user, using a >credential of some kind such as a command line password. I've thought >for a long time that we needed "gbean permissions" of some kind. Would >accessing the safe require permissions or be a login-type operation? >With enough permissions, do we need a safe at all? > >I'd like to know more :-) > >thanks >david jencks >>On Nov 20, 2005, at 11:59 PM, [EMAIL PROTECTED] wrote: >> An idea of including deployment plan into configuration was kicked >> around for some time now. I think that each configuration should >> include deployment plan. >> >> By itself, deployment plan is not a secret and as such it should not >> contain sensitive data that we do not want to disclose (passwords >> etc). >> >> So the idea would be not to hide deployment plan, but to externalize >> sensitive data. >> >> One way to externalize sensitive data is to have a "vault" gbean that >> can implement different qos vis keeping a secret, and have a reference >> to this vault in the deployment plan together with some alias to the >> secret in the vault: >> >> <reference name="vault">bla</reference> >> <attribute name="alias">myconfig.id.password</attribute> >> >> Vault by itself can provide different qos. The simpliest case is to >> have a file with all secrets in it and to install it in a secure >> location. One step up would be to assign a master key to the geronimo >> server at the deployment time, put it in a secure location and use it >> to encrypt all other secrets. And so on... >> >> If there is enough interest in this I can put it together >> >> Simon >> >> >>
