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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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. :)

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.

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.

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

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