WildFly Security Realms: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(31 intermediate revisions by the same user not shown)
Line 6: Line 6:
=Internal=
=Internal=


* [[WildFly Security#Subjects|WildFly Security]]
* [[WildFly Security Concepts#Security_Realms |WildFly Security Concepts]]


=Overview=
=Overview=
Line 29: Line 29:


For a better upper level picture of WildFly security, see [[WildFly Security Concepts]].
For a better upper level picture of WildFly security, see [[WildFly Security Concepts]].
=Relationship between a Security Realm and a Security Domain=
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[WildFly Security Concepts#Relationship_between_a_Security_Realm_and_a_Security_Domain|Relationship between a Security Realm and a Security Domain]]
</blockquote>


=The Digest Mechanism=
=The Digest Mechanism=


The digest mechanism used by the WildFly security realms is an authentication mechanism that authenticates the user by computing one-time, one-way hashes comprised of various pieces of information, including information stored in the users/passwords mapping property file. This allows WildFly to authenticate users without sending any passwords in plain text over network.
The digest mechanism (DIGEST-MD5) used by the WildFly security realms is an authentication mechanism that authenticates the user by computing one-time, one-way hashes comprised of various pieces of information, including information stored in the users/passwords mapping property file. This allows WildFly to authenticate users without sending any passwords in plain text over network.


The user file contains the mapping between the user name and the password hash.  
The user file contains the mapping between the user name and the password hash.  
Line 38: Line 44:
When a user attempts to authenticate, WildFly sends a one-time use number (nonce) to the client. The client generates a one-way has using their username, password, nonce and few other fields, and sends to WildFly instance the username, nonce and one-way hash. WildFly looks up the users's password hash and uses it along with the provided username, nonce and few other fields to generate another one-way hash in the same manner. If the hashes match, the user is authenticated.
When a user attempts to authenticate, WildFly sends a one-time use number (nonce) to the client. The client generates a one-way has using their username, password, nonce and few other fields, and sends to WildFly instance the username, nonce and one-way hash. WildFly looks up the users's password hash and uses it along with the provided username, nonce and few other fields to generate another one-way hash in the same manner. If the hashes match, the user is authenticated.


=Management Realm=
This is how a JBoss Remoting client performs a programmatic login: {{Internal|Remoting_WildFly_Subsystem_Concepts#JBoss_Remoting_Client-Side_Programmatic_Login|JBoss Remoting Client-Side Programmatic Login}}
 
=Local File-Based Authentication Mechanism=
 
JBoss has a local file-based authentication mechanism, also known as the "LOCAL" authentication mechanism, based on the fact that a local client has access to a file created by the server on the local file system, specifically in the $JBOSS_HOME/standalone/tmp/auth directory. If the client can read the file, then the username/password is not used and the local file-based authentication serves as the only authentication. The name of the user authenticated as such is specified in the configuration, and it is by default <span id='The_.24local_User'></span>"$local". The "LOCAL" mechanism automatically authenticates all local users, if configured, and is specifically provided for local tools running against this AS installation, form the same host, such as the [[WildFly CLI|CLI]].
 
{{Warn|Note that LOCAL authentication only works if <tt>jboss-cli.sh</tt> is run by the same UNIX user that runs the host controller.}}
 
==Local File-Based Authentication Configuration==


The ''management realm'' stores authentication and authorization information for the [[WildFly Management Interfaces#Security|management API]]. Further authentication mechanism can be configured as part of the <tt><management></tt> element in <tt>host.xml</tt> or <tt>standalone.xml</tt>. For more details see [[WildFly Management API Configuration]].
The LOCAL authentication mechanism can be configured under the <authentication> section of the <security-realm> configuration:


==The <tt>$local</tt> User==
<management>
    <security-realms>
          <security-realm name="ManagementRealm">
              <authentication>
                  <b><local default-user="$local" skip-group-loading="true"/></b>
                  ...
              </authentication>
              ...
          </security-realm>
    </security-realms>
  </management>


On start-up the server automatically adds a <tt>$local</tt> user to the Management Realm. This user is specifically provided for local tools running against this AS installation, form the same host, such as the [[WildFly CLI|CLI]]. Once connected via [[WildFly CLI|CLI]], the identity can be confirmed as follows:
Both the [[#Management_Realm|Management Realm]] and [[#Application_Realm|Application Realm]] allow local file-based authentication, if they are configured as shown above. For more details see [[WildFly Management API Configuration|Management API Configuration]]. Once connected via [[WildFly CLI|CLI]], the identity can be confirmed as follows:


<pre>
:whoami
:whoami
{
{
    "outcome" => "success",
    "outcome" => "success",
    "result" => {"identity" => {
    "result" => {"identity" => {
        "username" => "$local",
        "username" => "$local",
        "realm" => "ManagementRealm"
        "realm" => "ManagementRealm"
    }}
    }}
}
}
</pre>


Local authentication is automatically disabled if a user is specified when connecting the CLI.
Local authentication is automatically disabled if a user is specified when connecting the CLI.


<font color=red>TODO: understand how this really works, implementation details.</font>
=Management Realm=
 
The ''management realm'' stores authentication and authorization information for the [[WildFly Management Interfaces#Security|management API]]. Further authentication mechanism can be configured as part of the <tt><management></tt> element in <tt>host.xml</tt> or <tt>standalone.xml</tt>. For more details see [[WildFly Management API Configuration#Management_Realm_Configuration_Files|Management API Configuration - Management Realm Configuration Files]].
 
The management realm allows LOCAL authentication if configured as described here: [[#Local_File-Based_Authentication_Configuration|Local File-Based Authentication Configuration]].


=Application Realm=
=Application Realm=


The ''application realm'' stores authentication and authorization information for the deployed applications (web applications and EJBs). The security information is maintained in flat files. The application realm stores authentication and authorization information. The realm files can be modified at any time, updates after the server has started will be automatically detected. For more details see [[WildFly Management API Configuration#Application_Realm_Configuration_Files|Management API Configuration - Application Realm Configuration Files]].
The ''application realm'' stores authentication and authorization information for the deployed applications (web applications and EJBs).  
 
The management realm allows LOCAL authentication if configured as described here: [[#Local_File-Based_Authentication_Configuration|Local File-Based Authentication Configuration]].
 
For more details see [[WildFly Management API Configuration#Application_Realm_Configuration_Files|Management API Configuration - Application Realm Configuration Files]].


=Adding a New Security Realm=
=Adding a New Security Realm=
<font color=red>
TODO: https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.3/html-single/Security_Guide/index.html#chap-Security_Realms#Add_a_New_Security_Realm
</font>
=Adding Users to Security Realms=
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[Adding Users to WildFly Security Realms]]
</blockquote>
=Organizatorium=
* <font color=red> TODO: define org.jboss.as.domain.management.AuthenticationMechanism: LOCAL, CLIENT_CERT, DIGEST, PLAIN;</font>

Latest revision as of 05:17, 8 July 2017

External

Internal

Overview

A security realm is a WildFly-specific identity store of usernames, passwords and group membership information that can be used to authenticate users of the management interfaces, web applications and EJBs.

The security realm contains mappings between users and passwords, and users and roles - a mechanism for adding authentication and authorization to applications and JBoss management facilities and regular applications.

By default WildFly comes pre-configured with two realms:

Both of these use filesystem-based stores for users and group membership, and use a digest mechanism by default when authenticating.

New security realms can be configured. See Adding a New Security Realm.

The existing security realms can be reconfigured to use other authentication mechanisms, different from digest.

Security realms are not involved in any authorization decisions, however they can be configured to load a user's group membership information, which then can be subsequently used to make authorization decisions. The user is authenticated first, then the group membership information is loaded as part of a second step.

The management interfaces and the associates security realms are loaded as core services.

For a better upper level picture of WildFly security, see WildFly Security Concepts.

Relationship between a Security Realm and a Security Domain

Relationship between a Security Realm and a Security Domain

The Digest Mechanism

The digest mechanism (DIGEST-MD5) used by the WildFly security realms is an authentication mechanism that authenticates the user by computing one-time, one-way hashes comprised of various pieces of information, including information stored in the users/passwords mapping property file. This allows WildFly to authenticate users without sending any passwords in plain text over network.

The user file contains the mapping between the user name and the password hash.

When a user attempts to authenticate, WildFly sends a one-time use number (nonce) to the client. The client generates a one-way has using their username, password, nonce and few other fields, and sends to WildFly instance the username, nonce and one-way hash. WildFly looks up the users's password hash and uses it along with the provided username, nonce and few other fields to generate another one-way hash in the same manner. If the hashes match, the user is authenticated.

This is how a JBoss Remoting client performs a programmatic login:

JBoss Remoting Client-Side Programmatic Login

Local File-Based Authentication Mechanism

JBoss has a local file-based authentication mechanism, also known as the "LOCAL" authentication mechanism, based on the fact that a local client has access to a file created by the server on the local file system, specifically in the $JBOSS_HOME/standalone/tmp/auth directory. If the client can read the file, then the username/password is not used and the local file-based authentication serves as the only authentication. The name of the user authenticated as such is specified in the configuration, and it is by default "$local". The "LOCAL" mechanism automatically authenticates all local users, if configured, and is specifically provided for local tools running against this AS installation, form the same host, such as the CLI.


Note that LOCAL authentication only works if jboss-cli.sh is run by the same UNIX user that runs the host controller.

Local File-Based Authentication Configuration

The LOCAL authentication mechanism can be configured under the <authentication> section of the <security-realm> configuration:

<management>
    <security-realms>
         <security-realm name="ManagementRealm">
             <authentication>
                 <local default-user="$local" skip-group-loading="true"/>
                 ...
             </authentication>
             ...
         </security-realm>
    </security-realms>
 </management>

Both the Management Realm and Application Realm allow local file-based authentication, if they are configured as shown above. For more details see Management API Configuration. Once connected via CLI, the identity can be confirmed as follows:

:whoami
{
    "outcome" => "success",
    "result" => {"identity" => {
        "username" => "$local",
        "realm" => "ManagementRealm"
    }}
}

Local authentication is automatically disabled if a user is specified when connecting the CLI.

Management Realm

The management realm stores authentication and authorization information for the management API. Further authentication mechanism can be configured as part of the <management> element in host.xml or standalone.xml. For more details see Management API Configuration - Management Realm Configuration Files.

The management realm allows LOCAL authentication if configured as described here: Local File-Based Authentication Configuration.

Application Realm

The application realm stores authentication and authorization information for the deployed applications (web applications and EJBs).

The management realm allows LOCAL authentication if configured as described here: Local File-Based Authentication Configuration.

For more details see Management API Configuration - Application Realm Configuration Files.

Adding a New Security Realm

TODO: https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.3/html-single/Security_Guide/index.html#chap-Security_Realms#Add_a_New_Security_Realm

Adding Users to Security Realms

Adding Users to WildFly Security Realms

Organizatorium

  • TODO: define org.jboss.as.domain.management.AuthenticationMechanism: LOCAL, CLIENT_CERT, DIGEST, PLAIN;