Re: [jboss-as7-dev] Securing Attributes including passwords

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