[jboss-as7-dev] Securing Attributes including passwords

Brian Stansberry brian.stansberry at redhat.com
Thu Sep 1 11:41:24 EDT 2011


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
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat


More information about the jboss-as7-dev mailing list