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

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: -- Brian Stansberry Principal Software Engineer JBoss by Red Hat