wildfly-security/elytron-subsystem

Subsystem to enable configuration of Elytron within WildFly

elytron-subsystem's Issues

Add JDBC backed realm definitions.

Add JAAS SecurityRealm Definition

Domain definition only persisting 2 realms and dropping the rest.

Add KeyStore backed security realm.

Primarily the first KeyStore type we want to verify can be configured in the subsystem is the legacy properties file already in-use.

Secondly we do need to ensure the identity can be fully loaded and group membership information obtained.

Make the subsystem host capable

Further review of NSS backed SunPKCS#11 registration.

It appears that initialisation by a one time only event so reloads and redefining services is going to be problematic.

Eliminate the dummy realm.

It was only a temporary realm to get the subsystem development started.

Operation to generate key pair with self signed cert.

Convert to be 100% capabilities and requirements based.

ProviderLoader has capability Provider[]
KeyStore has capability KeyStore requires Provider[]
KeyStoreRealm has capability SecurityRealm required KeyStore
SecurityDomain has capability SecurityDomain requires SecurityRealm

Update KeyStoreAliasDefinition to be able to detect both of our PasswordEntry types.

At this point I am not going to go to the level of displaying the type of the password, I think that will be reserved for 1:1 ops where a callback may be needed.

Consider adding runtime attribute to report state of services

Initially thinking about this in the context of the KeyStore service but we are going to have quite a few places where runtime information in the model is directly from a service and also a number of operations invoking services directly.

Runtime information will be missing and operations will fail if their required service is not UP.

Adding the state as a runtime attribute will enable tooling to be more intuitive where a service is not actually available.

Custom provider registration

A couple of uses here: -

• Firstly the general ability to add a provider not known at all.
  • Secondly the addition of configuration for that provider e.g. a PKCS#11 provider may want a block of config also adding without relying on global config.

Add an aggregate realm definition.

The purpose of this is to allow a different realm for the authentication side to the authorization side.

Add LDAP backed realm definitions.

Convert domain and realm resources to be security-domain and security-realm

Within the Elytron subsystem we know that these are security related so the 'security' part has been dropped, however elsewhere in the app server and subsystem definitions these should be referenced as 'security-*' to avoid ambiguity - i.e. does a domain attribute have anything to do with our domain mode?

Where the KeyStore is exposed as Runtime model state handle any RuntimeExceptions

12:25:27,149 INFO  [org.jboss.as.controller.management-deprecated] (management-handler-thread - 6) WFLYCTL0028: Attribute password is deprecated, and it might be removed in future version!
12:25:54,917 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
    ("subsystem" => "elytron"),
    ("keystore" => "pkcs#11"),
    ("alias" => "darranl")
]): java.security.ProviderException: java.lang.UnsupportedOperationException
    at sun.security.pkcs11.P11KeyStore.engineGetCreationDate(P11KeyStore.java:401)
    at java.security.KeyStore.getCreationDate(KeyStore.java:1089)
    at org.wildfly.security.keystore.DelegatingKeyStoreSpi.engineGetCreationDate(DelegatingKeyStoreSpi.java:74)
    at java.security.KeyStore.getCreationDate(KeyStore.java:1089)
    at org.wildfly.security.keystore.DelegatingKeyStoreSpi.engineGetCreationDate(DelegatingKeyStoreSpi.java:74)
    at java.security.KeyStore.getCreationDate(KeyStore.java:1089)
    at org.wildfly.extension.elytron.KeyStoreAliasDefinition$1.performRuntime(KeyStoreAliasDefinition.java:90)

Generally these are not mentioned in the API - however it prevents the runtime op from executing so quietly handle this.

Add SSL Configuration

Within the WildFly project we have a bunch of SSL related tasks to unify configuration, the Elytron subsystem is probably that location.

Speaking with various projects they are happy to work with standard Java types, e.g. SSLContext, KeyManager, TrustManager provided we can make them available - this will become the basis for that.

Need to think in terms of these being capabilities exposed by the subsystem. the subsystem may need closer integration with the realms especially when it comes to things like trust manager integration. Once standardised as capabilities it should be possible for other subsystems to also provide these e.g. maybe the PicketLink subsystem will also provide an alternative way to obtain these.

Update the provider definitions so a configuration file can be provided to initialise the provider

Elytron provider registration

The Elytron provider needs to be registered.

Switch build to Java 8

Operation to convert between KeyStore types

We need operations to do the following:

• convert one keystore to another keystore type (updating the model accordingly)
• copy individual aliases between keystores

Ability to enable watching a KeyStore file for modifications.

Deliberately leave this one until the manual management ops are stable, did previously look at this from the perspective of a generic KeyStore in Elytron but IMO this is something that needs much closer integration with the subsystem to relate to the other actions being performed.

We will have some additional things to consider: -

• Suspend watches if the in-memory version is modified.
• Maybe some force attributes on the load / save operations if detected out of sync with filesystem.

Make the ServiceUtil classes generic.

They are all essentially following the same pattern.

• Construct a ServiceName given the simple name.
• Identify the simple name from an op and use it to construct the ServiceName
• Handle injection based on a specific type and the simple name to ServiceName conversion.

Allow a default SSLContext to be registered

Generally it will be preferred that subsystems that require SSL related capabilities depend on the actual services installed by Elytron, however there are some cases where libraries will depend on the default SSLSocketFactory and SSLServerSocketFactory instances. For these cases we should have a default SSLContext registered so at least they can take advantage of the capabilities we are providing.

Keep in mind a need for a difference in client and server behaviour as the client behaviour will need to delegate to the client config and not the server config.

Add Domain and Realm Definitions

i.e. Empty realms and domains that can cross reference them.

Operation to create certificate signing request.

Upgrade WildFly dependency for 9

With the core split for 9 we should be able to depend on the latest core.

Ensure all attributes on the KeyStoreDefinition take effect immediately.

By immediately I mean the service should be provided with the modified values. This will not trigger a reload or anything but next time save or load is called the new values will be used.

Add KeyStore definitions to XML and the model and implement loading.

This will also include exposing runtime management resources and operations to query the store.

Note: The querying must not expose any sensitive information such as private keys.

KeyStore load, save and initial modifications.

The modification at this stage will just be removal of an alias.

Add generic realm definition

Probably one to talk about first but potentially we may want user supplied realms to be definable within our subsystem.

Subsystem developers can always advertise their realm using capabilities and requirements but this may be too much for those that want to be able to supply a custom realm.

A could of points to consider: -

• Do we need a generic way to define requirements so these can be injected?
• How will custom realms be configured.

Provider Resource Clean Up

The TODO list!

• Make sure all unchecked conversions are checked.
• Ensure mutual exclusivity of model attributes.

Review existing resources and add to attribute groups as appropriate.

Make entire subsystem private

Generally the whole subsystem should be private, other subsystems should be depending on services that return standard types which are either standard Java types or API types defined by Elytron.

In theory the whole subsystem could be replaced by an alternative implementation that provides services that also implement the same APIs.

Also want to ensure external subsystems don't make assumptions about naming conventions used for Elytron services.

For now however until we get true capabilities and requirements support some utility may need to be made available for other subsystems to set the dependencies they need - this could be accomplished by some form of service name factory that would allow external subsystems to ask for a service name for a service that returns a KeyStore named X.

Update the provider definitions so key/value based configuration can be provided.

This is only going to be applicable when the class names have been supplied as this will be configuration to specific providers - each of which will require their own set of key/value pairs.

Add the LDAP backed realm.

Operation to import certificate as a trusted certificate.

Operation to import certificate as result of certificate signing request.

Add 'provider-loader-ref' support to KeyStore definition

i.e. instead of using globally registered providers the Provider[] array from the service will be used instead.

This will also need some form of resolver util although that may live within Elytron.

The util will need to take a Provider[](This means it will be compatible with a service supplied array or a Security.getProviders%28%29 array).

-1 We may have a provider name specified, if specified this MUST match.
-2 We know the service type we are looking for, obviously the provider must be able to provide this.
-3 We know the algorithm so this must match.

I think in general algorithm never gets to be optional.

Add support for defining security properties.

Probably best to just match existing approach for system properties.

Add checkstyle to the build

Add properties backed security realm definition

Ability to sign a CSR

Add a Logger class to the subsystem

Runtime attribute and ability to track if KeyStore modified since last save / load

To simplify things to start with the subsystem is actually going to wrap the KeyStore to make it unmodifiable by external subsystems referencing the KeyStore but within the subsystem we should be able to track if it has been modified since the last save / reload.

We also need something to be able to take into account a reverted load as if it had previously been modified the load could clear a flag but a revert could reset the flag.

Represent the KeyStore.Entry.Attribute name / value pairs.

Add a generic security realm definition

We will add a new interface to the subsystem 'ConfigurableSecurityRealm' which will have an initialize method that takes a Map of Strings, this can be used to provide configuration for custom user realms.

Generally however the preferred approach is that the implementer of a new realm would register it as a capability from their own subsystem then they can have their own strongly defined configuration model.

Long term we may look for more advanced extensibility solutions.

Further work on the Provider resources.

Where the service returns a list of providers we should also be able to include the globally registered providers.

Also one list could possibly reference another list, this way small definitions can be created followed by an aggregation.

Domain definition should check the default realm is actually referenced.

At the moment a security domain can be defined with a default realm name that does not match any of the realms actually referenced.

Add operations to add and a new provider to the specific place in the list and to remove specific providers.

The representation of the providers attribute contains an index that should be used as the basis for this.