Red Hat
Aug 17, 2017
by Peter Skopek

Introduction

Useful reading to start with is WildFly documentation, particularly Domain Setup and Core Management Concepts. To start just download WildFly 11.0.0.Beta1 Application Server Distribution here and you are ready to start.

We will used default configuration as provided in WildFly.
To start server in domain mode run ./bin/domain.sh (assuming WildFly home directory is your current one).

Open second terminal window and run ./bin/jboss-cli.sh --connect to start CLI  for entering commands.

Create Credential Store Resource

In the default WildFly domain configuration we have two servers started "server-one" and "server-two". Both belongs to the "main-server-group" which runs profile "full" (check via CLI:  
/server-group=main-server-group:read-resource

We can start then to create credential store named "test" in profile=full.
Here is the command:
/profile=full/subsystem=elytron/credential-store=test:add(relative-to=jboss.server.data.dir,location=test.store,credential-reference={clear-text="secret2"},create=true)

Note the /profile=full/ prefix of the resource address. There is no need to define credential store resource at each server. Each server running profile "full" contains our credential store. Therefore it is good idea to locate storage file at server data directory (relative-to=jboss.server.data.dir) as this makes manageable for more servers (and directory is already there).

Runtime operations

As we have successfully defined credential store we can add some aliases through CLI commands. It is similar to standalone server mode, but we have to locate the runtime resource exposed by each individual server.
For our default domain configuration it is following command:
/host=master/server=server-one/subsystem=elytron/credential-store=test:add-alias(alias=db, secret-value="db_secret_password")

This will create alias "db" at server "server-one" at host "master".

/host=master/server=server-two/subsystem=elytron/credential-store=test:add-alias(alias=jms_server, secret-value="jms_secret_password")

This one created alias "jms_server" at "server-two" running at host "master".

Let's check the content of credential stores at each server:

/host=master/server=server-one/subsystem=elytron/credential-store=test:read-aliases()
{
"outcome" => "success",
"result" => ["db"]
}
/host=master/server=server-two/subsystem=elytron/credential-store=test:read-aliases()
{
"outcome" => "success",
"result" => ["jms_server"]
}

Note that content of each credential store is different.
Other operations could be found in this blog post. Just don't forget to locate your server and host to manipulate proper credential store.

Referencing aliases

Each credential store runs at respective server so all credential references used at this sever have to be contained at each credential store. For now we don't support bulk operations across server-groups, so admins must define them for each server individually.
While provisioning another server storage file for credential store can be prepared upfront using WildFly Elytron Tool and distributed to individual server by some secure means. Then it is enough to define credential store and all aliases are available.

Using shared storage file for credential store

One can decide to share one storage file through more servers. There is risk of inconsistency when the credential storage is manipulated from more processes. This is not supported but we cannot really avoid it, so we defined special option in our default credential store implementation called "modifiable" (true/false). Which prevents credential store modifications and therefore user can be sure to control what process can modify the storage.
Note that when implementing your own credential store there is a method   org.wildfly.security.credential.store.CredentialStoreSpi#isModifiable which controls this functionality.











Original Post