[jboss-as7-dev] Securing Attributes including passwords

[Anil Saldhana]

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