anchor.diff:  
   For the HTTP connections we now define a HTTP authentication factory using the previously defined resources and it is configured to support CLIENT_CERT and DIGEST authentication.
   
  -----
  -./subsystem=elytron/http-authentication-factory=client-cert-digest:add(http-server-mechanism-factory=global, \
  -  security-domain=client-cert-domain, \
  +Because our security realm is not able to verify client certificates (properties realm verifies passwords only), we need to add configuring mechanism factory first, which will disable certificate verification against the security realm:
  +
  +----
  +/subsystem=elytron/configurable-http-server-mechanism-factory=configured-cert:add(http-server-mechanism-factory=global, properties={org.wildfly.security.http.skip-certificate-verification=true})
  +----
  +
  +As following, we can create HTTP authentication alone:
  +
  +----
  +./subsystem=elytron/http-authentication-factory=client-cert-digest:add(http-server-mechanism-factory=configured-cert, \
  +  security-domain=ManagementDomain, \
    mechanism-configurations=[{ \
     mechanism-name=CLIENT_CERT, \
  -  realm-mapper=key-store-realm, \
     pre-realm-principal-transformer=x500-decoder}, \
    {mechanism-name=DIGEST, mechanism-realm-configurations=[{realm-name=ManagementRealm}]}])
   ----
  
positive.code: <configuration>
      <authentication-client xmlns="urn:elytron:1.0">
          <key-stores>
              <key-store name="ladybird" type="jks" >
                  <file name="ladybird.keystore"/>
                  <key-store-clear-password password="Elytron" />
              </key-store>
              <key-store name="ca" type="jks">
                  <file name="ca.truststore"/>
                  <key-store-clear-password password="Elytron" />
              </key-store>
          </key-stores>
          <ssl-context-rules>
  
negative.code: 
  This section will cover how to create the various resources required to achieve CLIENT_CERT authentication with fallback to username / password authentication for both HTTP and SASL (i.e. Remoting) - both are being covered at the same time as predominantly they require the same core configuration, it is not until the definition of the authentication factories that the configuration becomes really specific.
  
  This suppose you have configured legacy Client-Cert SSL authentication using `truststore` in legacy `security-realm`, for example by link:Admin_Guide.html#src-557075_AdminGuide-AddClient-CerttoSSL[Admin Guide#Add Client-Cert to SSL], and your configuration looks like:
  
  [source, xml]
  ----
  <security-realm name="ManagementRealm">
    <server-identities>
      <ssl>
        <keystore path="server.keystore" relative-to="jboss.server.config.dir" keystore-password="keystore_password" alias="server" key-password="key_password" />
      </ssl>
    </server-identities>
    <authentication>
      <truststore path="server.truststore" relative-to="jboss.server.config.dir" keystore-password="truststore_password" />
      <local default-user="$local"/>
      <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
    </authentication>
  </security-realm>
  ----
  
  This also suppose you have already followed link:Simple_SSL_Migration.adoc[Simple SSL Migration] section, so your partialy migrated configuration looks like:
  
  [source, xml]
  ----
  <subsystem xmlns="urn:wildfly:elytron:1.0" ...>
      ...
      <tls>
          <key-stores>
              <key-store name="LocalhostKeyStore">
                  <credential-reference clear-text="keystore_password"/>
                  <implementation type="JKS"/>
                  <file path="server.keystore" relative-to="jboss.server.config.dir"/>
              </key-store>
              <key-store name="TrustStore">
                  <credential-reference clear-text="truststore_password"/>
                  <implementation type="JKS"/>
                  <file path="server.truststore" relative-to="jboss.server.config.dir"/>
              </key-store>
          </key-stores>
          <key-managers>
              <key-manager name="LocalhostKeyManager" key-store="LocalhostKeyStore" alias-filter="server">
                  <credential-reference clear-text="key_password"/>
              </key-manager>
          </key-managers>
          <trust-managers>
              <trust-manager name="TrustManager" key-store="TrustStore"/>
          </trust-managers>
          <server-ssl-contexts>
              <server-ssl-context name="LocalhostSslContext" need-client-auth="true" key-manager="LocalhostKeyManager" trust-manager="TrustManager"/>
          </server-ssl-contexts>
      </tls>
  </subsystem>
  ----
  
  However following steps are needed to be user identity provided to your applications or management console.
  
  == Realms and Domains
  
  We use users stored in standard properties files, so we can predefined Elytron security domain `ManagementDomain` and realm `ManagementRealm`:
  
  [source, xml]
  ----
      <security-domains>
          <security-domain name="ManagementDomain" default-realm="ManagementRealm" permission-mapper="default-permission-mapper">
              <realm name="ManagementRealm" role-decoder="groups-to-roles"/>
              <realm name="local"/>
          </security-domain>
      </security-domains>
      <security-realms>
          <properties-realm name="ManagementRealm">
              <users-properties path="mgmt-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="ManagementRealm"/>
              <groups-properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/>
          </properties-realm>
      </security-realms>
  ----
  
  The security realm will be used in two situations:
  * Authentication in password fallback case, when certificate authentication fails
  * Authorization in both - password and certificate auth - cases - the realm will provide roles of individual users
  
  This mean, for any client certificate there have to exists user in the security realm.
  
  == Principal decoder
  
  When certificate authentication is used and the security realm accepts usernames to resolve an identity, there have to be defined way to obtain username from a client certificate.
  In this case we will use first CN attribute in certificate subject:
  
  ----
  ./subsystem=elytron/x500-attribute-principal-decoder=x500-decoder:add(attribute-name=CN, maximum-segments=1)
  ----
  
  Resulting in: -
  [source, xml]
  ----
  <subsystem xmlns="urn:wildfly:elytron:1.1" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
    ...
    <mappers>
      ...
      <x500-attribute-principal-decoder name="x500-decoder" attribute-name="CN" maximum-segments="1"/>
      ...
    </mappers>
    ...
  </subsystem>
  