2:11 p.m.
Brian,
I want to make it clear that when I meant attribute, it is not referring
to xml attribute. But more like a property of a bean or POJO or such. A
password is one such attribute. :)
Two potentials:
1) I envision an xml attribute vaultRef="vaultBlock_attributeName" to
the xml element which indicates the value should be obtained from the
vault.
2) XML attribute says secure="true" and the text value of the element
gives the "vaultBlock_attributeName" The presence of secure xml
attribute indicates that we need to get the value from the vault.
VaultBlock is analogous to security domains. Just to group various
attributes of an entity.
Regards,
Anil
On 09/01/2011 10:41 AM, Brian Stansberry wrote:
Next questions I have are:
1) How we go about storing these secured attributes in the configuration
model.
2) How tools go about dealing with them (e.g. represent in a console
that an attribute value is really a key to be looked up in a vault and
not the password itself).
3) Provide controlled access to the vault to operation handlers.
The last one should properly be a separate discussion.
For 1) and 2) the simple solution is just to store a string in the
model, and custom code in OperationStepHandler impls that deal with
potentially secure attributes reads the string, decides if the string is
a vault key, and accesses whatever API we provide in 3) to resolve the
attribute.
But simple always has problems:
a) Clients reading the management model have no clue the string is a key
and not the actual value.
b) Further to a), if the metadata for an attribute says it's of type
ModelType.INT, the client is liable to try to read it as an int, which
will fail.
c) It's not particularly generic on the server side. Custom code in the
parser to accept arbitrary string data in the XML instead of, e.g. an
int called for in the schema. Custom code in handlers to resolve the
string into the vault's value.
We already have a solution for some of these problems though, in the
ModelType.EXPRESSION type that jboss-dmr supports. In a way, these vault
keys are just another form of expression value, the difference is just
in how the value is resolved: from the vault or from the system properties.
It's tempting to use the expression syntax ("${my.secure.key}") for
these, treat these secure attribute keys the same as other expression
values, and reduce the task to item 3), providing controlled access to
the vault to operation handlers.
Thoughts?
On 8/31/11 5:50 PM, Anil Saldhana wrote:
> The location of the vault file is an option.
> ========
> ENC_FILE_DIR: the location where the encoded files will be kept. End
> with "/" or "\" based on your platform
> ========
>
> The config for the vault is a one type operation at the jvm level. So I
> put it in the security subsystem. I will put it under host and standalone.
>
> ========
> (05:47:22 PM) bstansberry: asaldhan: yes. i'm suggesting that element
> become part of the core config, as a child of<host> or<standalone>. It
> should appear in the schema prior to any other element that needs data
> from the vault.
> =============
>
>
> On 08/31/2011 03:30 PM, Brian Stansberry wrote:
>> No opposition.
>>
>> Where do you see the vault being located on the filesystem?
>>
>> Also, right now the vault config is in the security subsystem, but to
>> make it usable by the core AS I think we'll need to pull it out and make
>> it an element under<standalone>,<host> etc.
>>
>> On 8/31/11 2:10 PM, Anil Saldhana wrote:
>>> Hi All,
>>> I am currently working on providing a means to secure attributes such
>>> as passwords. I have come up with the notion of a vault that stores the
>>> attributes
>>>
>>> JIRA: https://issues.jboss.org/browse/AS7-1622
>>> Discussion: http://community.jboss.org/thread/170598?tstart=0
>>>
>>> I need to create two scripts (vault.sh and vault.bat) in the bin
>>> directory of the AS.
>>>
>>> Is there any opposition to creating the scripts?
>>>
>>> Regards,
>>> Anil