[jboss-as7-dev] Securing Attributes including passwords

[Anil Saldhana]

I have put this in place with the commit for the datasource password:
https://github.com/anilsaldhana/jboss-as/commit/496a09326cb07caa6cde0e616a48a00d95f7a7de

A writeup:
http://community.jboss.org/wiki/JBossAS7SecuringPasswords

On 09/01/2011 04:56 PM, Anil Saldhana wrote:
> I was thinking something like:
>
> <someElement secure="true">vaultBlock_attributeName</someElement>
>
> which would be a representation of:
> <someElement>valueThatShouldNotBeExposed</someElement>
> Maybe attributeName should be called elementName.
>
>
> Now that someElement may infact be:
>
> <subsystem  name="messaging">
> <password>mypassword</password>
> <creditCard>1111122222222222222</creditCard>
> </subsystem>
>
> which would be safely vaulted as:
> <subsystem name="messaging">
> <password secure="true">messaging_password</password>
> <creditCard secure="true">messaging_creditCard</creditCard>
> </subsystem>
>
>
>
> On 09/01/2011 04:07 PM, Brian Stansberry wrote:
>> On 9/1/11 2:11 PM, Anil Saldhana wrote:
>>> 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. :)
>>>
>> Yeah, we're on the same page. When I talk about an attribute I mean
>> what's described in the "Attributes" section of
>> https://docs.jboss.org/author/display/AS7/Management+resources
>>
>>> 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.
>> Ok, this then becomes a choice, between a vaultRef attribute or a
>> non-vault attribute, e.g. a password="". (I'm assuming here we don't
>> force the use of a vault.) The model stores both attributes, but only
>> one is defined. That works and is simple; only downside is it limits use
>> of the vault to elements we specifically code support for; it's not
>> generic. That's probably fine.
>>
>>> 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.
>>>
>> I much prefer the other. In the model we need to store 2 pieces of
>> information, "secure" and, say, "password". The meaning of the 2nd
>> varies depending on the value of the first, and limits the usage of this
>> pattern to string attributes.
>>
>> I think for the actual use case your 1) above is better than what I was
>> talking about in my last post, since yours follows the KISS principle.
>> But to clarify a bit what I meant:
>>
>> <some-element password="${vaultBlock_attributeName}" ...>
>>
>> Only one attribute.
>>
>> The parser recognizes that syntax and stores the value in a ModelNode of
>> type ModelType.EXPRESSION, instead of ModelType.STRING.[1] The metadata
>> for the attribute declares that an expression is allowed for the
>> attribute. When a client reads the model they get back a node of
>> ModelType.EXPRESSION, which tells the client the value is some sort of
>> unresolved key, not the ultimate value. The client already has to be
>> able to deal with this kind of thing since we use it for system-property
>> substitution. On the server side any code working with that model node
>> can pass it off to a standard method (probably in the OperationContext)
>> that can see it's ModelType.EXPRESSION and resolve it against the vault.
>> All of this is generic so it can easily be applied to any attribute.
>>
>>
>> [1] See
>> org.jboss.as.controller.parsing.ParseUtils.parsePossibleExpression(String value)
>>
>>> 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