WildFly Elytron 1.0.0.Alpha3 Released

At the end of last week we released WildFly Elytron 1.0.0.Alpha3

http://repo1.maven.org/maven2/org/wildfly/security/wildfly-elytron/1.0.0.Alpha3/

WildFly Elytron will be providing both SASL and HTTP authentication mechanisms for use within the application server, where possible stronger authentication mechanisms will be preferred over weaker mechanisms - there are challenges in achieving this but our ideal situation is to have no re-usable password representations transmitted over the network and also no passwords stored in reversible format on the local file system.

The 1.0.0.Alpha3 release has primarily been focussed on adding capabilities to the project to enable administrators to define policies to use when selecting SASL mechanisms and also some custom settings for when a mechanism is actually created.

• Ability to specify protocol passed into the mechanism.
• Ability to specify server-name passed into the mechanism.
• Definition of properties to pass into mechanism for available mechanism evaluation and mechanism creation.
• Filtering of mechanisms by name.
• Filtering of mechanisms by name and provider.
• Mechanism loading from a Provider[]
• Service loader based mechanism loading from a provided ClassLoader.
• Mechanism filtering based on supported credentials.

For the final item in that list at it's core the APIs that are being developers within WildFly Elytron are to enable a closer integration between the repositories that hold identity information and the authentication mechanisms.  A SecurityRealm is essentially the API used to interact with the repository of identities, from this we also obtain a RealmIdentity to represent an individual identity: -

As you can see from the above example both of these interfaces have a getCredentialSupport method, this method allows us to verify which credential types are supported in different situations and subsequently the mechanism filtering added in this release allows us to tailor the available authentication mechanisms to those actually compatible with the underlying realms.

In addition to the work on SASL based mechanisms selection the following Jira issues have also been resolved this release.

Release Notes - WildFly Elytron - Version 1.0.0.Alpha3

• [ELY-247] - NullPointerException in SecurityProviderSaslServerFactory (Not all providers return services)
• [ELY-227] - Add attribute mapping to Jdbc Security Realm
• [ELY-175] - SASL mechanism availability should take into account credential support.
• [ELY-189] - Support One-Time-Password SASL Mechanism
• [ELY-197] - Add mechanism selection policies to the security domains.
• [ELY-237] - Make it possible to configure the realm used on the client
• [ELY-238] - Recognise realm callback on digest server, and make authorize callback come last
• [ELY-239] - Make Anonumous auth set the anonymous principal name
• [ELY-242] - Delegating SaslServerFactory supporting properties
• [ELY-250] - Release WildFly Elytron 1.0.0.Alpha3
• [ELY-33] - Identity Loading
• [ELY-198] - Allow the association of Provider[] with a security domain and add support for mechanism loading.
• [ELY-219] - Process subject roles in JaasAuthorizationIdentity
• [ELY-223] - Add tests for the filesystem-backed realm
• [ELY-244] - The properties map in the sasl factories should be Map<String, ?> not Map<String, Object>
• [ELY-246] - Add github references to the pom

Next Release

The next release will be 1.0.0.Alpha4, the main feature to be included in that release will be the new APIs for HTTP authentication and an equivalent set of mechanism selection policies to allow an administrator control over HTTP authentication for their application server.

Upcomming WildFly Security Changes

For those of you that follow the WildFly development discussions you may be aware that we have a number of engineers currently engaged in a project called WildFly Elytron, for those not following essentially WildFly Elytron is a set of APIs and SPIs for application server security.  Although being developed to meet current requirements identified for the WildFly application server WildFly Elytron is a stand-alone library that could theoretically be used in other Java server environments.

The Need for Change

Historically application server security had been provided by making use of JAAS with the use of JAAS LoginModule implementations to verify a callers principal and credential combination, in the early stages of application servers this met the requirements fairly well - however in the modern age as increasing focus is given to security we find that this simple principal / credential pairing becomes harder and harder to use effectively.

As JBoss AS7 was developed our preference was to switch to stronger authentication mechanisms, for our native communication this meant a switch to SASL based authentication bound to the connection.  Due to incompatibility with JAAS this led us to a situation where we have two different security solutions within the application server, one focussed on SASL compatibility and one focussed on the legacy approach of principal / credential validation with integration between the two.

Having two different security solutions solving the same problem from completely different perspectives has let to a lot of confusion amongst users and from our perspective has left it difficult to provide new features - this has led to the initiation of the Elytron project to provide a single unified security solution across the whole application server.

Triangle of Compromises

Over the years working on security software within the application server I have come to the conclusion that whatever you do is always going to be bound by a triangle of compromises, enhance one node of the triangle and you risk reducing one or both of the other two.

Looking at a couple of examples.

Say you address how the passwords are stored, a common approach used here is a strong one way salted hash, if the storage is compromised at worst an attacker has an irreversible representation of the password that is next to useless to them without an expensive brute force search to attempt to identity the original password.  In the context of the triangle however the authentication mechanism you use for this password will now need to have dropped to plain text transmission, this may be countered buy using TLS on the connection but within the heap of the application server a plain text copy of the password will reside for some time.

Another option may be that some form of one time password is used instead, this improves the situation for both storage security and network security as the whole point of these passwords is that even if they are intercepted they can only be used once - the compromise however now is that usability is affected.

When an application server is deployed it is the role of the administrator to review these options in the context of their own installation, as an application server vendor it is not our role to prescribe the solution to be used instead our role is to provide the capabilities and options to allow the administrator to make these decisions and that is one of the main aims of the Elytron project.

What will Elytron Provide?

As mentioned above there are two predominant requirements of this project: -

1. Provide a unified security solution across the application server.
2. Give administrators the tools they need so that they can make decisions to configure their own environment effectively.

This is not an exhaustive list but here are some of the key areas we are looking to address: -

1. Consistent use of terminology across the application server including consistent configuration across the server.
2. Closer relationship between TLS configuration and authentication.
3. A unified re-usable approach to configuration 
4. Better client side control of the identity used to execute requests.
5. Propagation of identities within different deployments in the same application server.
6. Propagation of identities to a remote application server.

Underlying all of this is the emphasis on making sure stronger approaches to security are made available whilst simplifying the steps needed to achieve them.

What Next?

Following on from this will be a series of blog posts looking both at the APIs and SPIs of the Elytron project and how these will be represented in the application server in the form of the new subsystem currently being developed to expose this.

Related Links

Elytron Jira Project - https://issues.jboss.org/browse/ELY
WildFly Elytron GitHub - https://github.com/wildfly-security/wildfly-elytron