If you are not familiar with building WildFly have a look at HackingOnWildFly.
If you want to access a nightly build they are available from WildFly-latest-master.
Introduction
This blog post is the first part of a two part article on how to enable Keberos authentication for Remoting within WildFly 9, in Part 1 I discuss how to enable Keberos authentication for use with the CLI for managing the application server which makes use of JBoss Remoting to communicate with the server.In Part 2 I will be looking at how to take an existing secured EJB deployment from within the quickstarts and enable Kerberos based authentication.
In a previous blog post WildFly 9 - Kerberos Authentication for Domain Management Over HTTP I have already described a lot of the steps required to enable Kerberos authentication for HTTP, for the steps that are also applicable for authentication with Remoting I will briefly mention them but will not duplicate the descriptions here.
Service Principals
One important aspect of Kerberos based authentication is that the service requiring authentication needs to be represented by it's own service principal, the naming of this principal is in the form '{service_name}/{hostname}' - where HTTP servers are secured using Kerberos the service_name is 'HTTP' - however for Remoting the service_name is expected to be 'remote'.My Environment
My test environment that I am using for the basis of this blog post is the same as I described previously, the main difference here is that now I have a service principal called remote/web.dal.wildfly.org@DAL.WILDFLY.ORG which is in a keytab called remote.keytab.
As before any example commands will need to be updated to reflect your own environment.
Configuration Updates
As with the previous blog post system properties can be set as an easy way to define the realm name and the address of the KDC, after that similar updates also need to be made to the ManagementRealm: -
- Add a server identity for Kerberos.
- Add the keytab for the remote service principal.
- Add kerberos to the authentication resource of the security domain.
- Reload the server.
Steps 1, 3, and 4 are identical to those performed previously but in this example I would use the following command to add my remote keytab.
[standalone@web.dal.wildfly.org:9990 /] ./core-service=management/security-realm=ManagementRealm/server-identity=kerberos/keytab=remote\/web.dal.wildfly.org@DAL.WILDFLY.ORG:add(path=remote.keytab, relative-to=jboss.server.config.dir, debug=true)
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
Running the CLI
As before I have used the kinit command to obtain my own ticket granting ticket from the KDC: -
[darranl@localhost bin]$ kinit darranl@DAL.WILDFLY.ORG
Password for darranl@DAL.WILDFLY.ORG:
[darranl@localhost bin]$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: darranl@DAL.WILDFLY.ORG
Valid starting Expires Service principal
27/11/14 17:44:50 28/11/14 17:44:47 krbtgt/DAL.WILDFLY.ORG@DAL.WILDFLY.ORG
renew until 04/12/14 17:44:47
The next step is to start the CLI, as I start the CLI I set three system properties: -
- -Djava.security.krb5.realm=DAL.WILDFLY.ORG
- -Djava.security.krb5.kdc=kdc.dal.wildfly.org
- -Djavax.security.auth.useSubjectCredsOnly=false
The first two could be optional depending on local environmental settings but the third one is important as this allows the GSSAPI implementation to make use of the identity managed at the OS level.
In the case of my testing I am running the CLI on the same machine that I am running the application server so it is also important to ensure I disable local authentication otherwise Kerberos authentication will not get a chance to be used so I add the argument --no-local-auth.
This means the resulting command is: -
[darranl@localhost bin]$ ./jboss-cli.sh -c --controller=web.dal.wildfly.org \
--no-local-auth -Djava.security.krb5.realm=DAL.WILDFLY.ORG \
-Djava.security.krb5.kdc=kdc.dal.wildfly.org \
-Djavax.security.auth.useSubjectCredsOnly=false [standalone@web.dal.wildfly.org:9990 /]
I can execute the :whoami command to double check the user I am authenticated as.
[standalone@web.dal.wildfly.org:9990 /] :whoami
{
"outcome" => "success",
"result" => {"identity" => {
"username" => "darranl",
"realm" => "ManagementRealm"
}}
}
