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

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