[jboss-as7-dev] Securing Attributes including passwords

[Anil Saldhana]

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