-
Language:
English
-
Language:
English
Red Hat Training
A Red Hat training course is available for Red Hat JBoss Data Virtualization
Security Guide
This guide is intended for administrators
Red Hat Customer Content Services
Abstract
Chapter 1. JBoss EAP Security Domains
1.1. About Security Domains
1.2. About Authentication
1.3. Configure Authentication in a Security Domain
Procedure 1.1. Setup Authentication Settings for a Security Domain
Open the security domain's detailed view.
- Click the Configuration label at the top of the management console.
- Select the profile to modify from the Profile selection box at the top left of the Profile view.
Note
You should only select a profile if you are running Red Hat JBoss Data Virtualizaton in domain mode. - Expand the Security menu, and select Security Domains.
- Click the View link for the security domain you want to edit.
Navigate to the Authentication subsystem configuration.
Select the Authentication label at the top of the view if it is not already selected.The configuration area is divided into two areas: Login Modules and Details. The login module is the basic unit of configuration. A security domain can include several login modules, each of which can include several attributes and options.Add an authentication module.
Click Add to add a JAAS authentication module. Fill in the details for your module.The Code is the class name of the module. The Flag setting controls how the module relates to other authentication modules within the same security domain.Explanation of the FlagsThe Java Enterprise Edition 6 specification provides the following explanation of the flags for security modules. The following list is taken from https://docs.oracle.com/javase/6/docs/api/javax/security/auth/login/Configuration.html. Refer to that document for more detailed information.
Flag Details required The LoginModule is required to succeed. If it succeeds or fails, authentication still continues to proceed down the LoginModule list.requisite LoginModule is required to succeed. If it succeeds, authentication continues down the LoginModule list. If it fails, control immediately returns to the application (authentication does not proceed down the LoginModule list).sufficient The LoginModule is not required to succeed. If it does succeed, control immediately returns to the application (authentication does not proceed down the LoginModule list). If it fails, authentication continues down the LoginModule list.optional The LoginModule is not required to succeed. If it succeeds or fails, authentication still continues to proceed down the LoginModule list.Edit authentication settings
After you have added your module, you can modify its Code or Flags by clicking Edit in the Details section of the screen. Be sure the Attributes tab is selected.Optional: Add or remove module options.
If you need to add options to your module, click its entry in the Login Modules list, and select the Module Options tab in the Details section of the page. Click the Add button, and provide the key and value for the option. Use the Remove button to remove an option.- Reload the Red Hat JBoss Data Virtualization server to make the authentication module changes available to applications.
Your authentication module is added to the security domain, and is immediately available to applications which use the security domain.
jboss.security.security_domain
Module Option
By default, each login module defined in a security domain has the jboss.security.security_domain
module option added to it automatically. This option causes problems with login modules which check to make sure that only known options are defined. The IBM Kerberos login module, com.ibm.security.auth.module.Krb5LoginModule
is one of these.
true
when starting JBoss EAP 6. Add the following to your start-up parameters.
-Djboss.security.disable.secdomain.option=true
1.4. About Authorization
1.5. Configure Authorization in a Security Domain
Procedure 1.2. Setup Authorization in a Security Domain
Open the security domain's detailed view.
- Click the Configuration label at the top of the management console.
- In a managed domain, select the profile to modify from the Profile drop down box at the top left.
- Expand the Security menu item, and select Security Domains.
- Click the View link for the security domain you want to edit.
Navigate to the Authorization subsystem configuration.
Select the Authorization label at the top of the screen.The configuration area is divided into two areas: Policies and Details. The policy module is the basic unit of configuration. A security domain can include several authorization policies, each of which can include several attributes and options.Add a policy.
Click Add to add a JAAS authorization policy module. Fill in the details for your module.The Code is the class name of the module. The Flag controls how the module relates to other authorization policy modules within the same security domain.Explanation of the FlagsThe Java Enterprise Edition 6 specification provides the following explanation of the flags for security modules. The following list is taken from https://docs.oracle.com/javase/6/docs/api/javax/security/auth/login/Configuration.html. Refer to that document for more detailed information.
Flag Details required The policy module is required to succeed. If it succeeds or fails, authorization still continues to proceed down the policy module list.requisite The policy module is required to succeed. If it succeeds, authorization continues down the policy module list. If it fails, control immediately returns to the application (authorization does not proceed down the poicy module list).sufficient The policy module is not required to succeed. If it does succeed, control immediately returns to the application (authorization does not proceed down the policy module list). If it fails, authorization continues down the policy module list.optional The policy module is not required to succeed. If it succeeds or fails, authorization still continues to proceed down the policy module list.Edit authorization settings
After you have added your module, you can modify its Code or Flags by clicking Edit in the Details section of the screen. Be sure the Attributes tab is selected.Optional: Add or remove module options.
If you need to add options to your module, click its entry in the Policies list, and select the Module Options tab in the Details section of the page. Click Add and provide the key and value for the option. Use the Remove button to remove an option.
Your authorization policy module is added to the security domain. Reload the server for it to become available.
1.6. Encryption
- Teiid Transports
- Teiid provides built-in support for JDBC/ODBC over SSL. JDBC defaults to just sensitive message encryption (login mode), while ODBC (the pg transport) defaults to just clear text passwords if using simple username/password authentication.The Red Hat JBoss EAP instance must be configured for SSL as well so that any web services consuming Teiid may use SSL.
- Configuration
- Passwords in configuration files are stored as a hash.
- Source Access
- Encrypting remote source access is the responsibility for the resource adapter and library/driver used to access the source system.
- Temporary Data
- Teiid temporary data which can be stored on the file system as configured by the BufferManager may optionally be encrypted. Set the buffer-service-encrypt-files property to true on the Teiid subsystem to use 128-bit AES to encrypt any files written by the BufferManager. A new symmetric key will be generated for each start of the Teiid system on each server. A performance hit will be seen for processing that is memory intensive such that data typically spills to disk. This setting does not affect how VDBs (either the artifact or an exploded form) or log files are written to disk.
1.7. Temporary Data
Chapter 2. Configuring Authentication and Authorization for JBoss Data Virtualization
2.1. Client Authentication
Note
2.2. Data Source Authentication
2.3. Pass-Through Authentication
Procedure 2.1. Configure Pass-Through Authentication
- Change the Teiid security-domain name in the embedded "transport" section to the same name as your application's security domain name. (You can make this change via the CLI or by editing the standalone.xml file if you are running the product in standalone mode.).
Important
The security domain must be a JAAS-based LoginModule and your client application must obtain its Teiid connection using a Local Connection with the PassthroughAuthentication connection flag set to true.
2.4. Data Roles
<mapped-role-name>
tags. (Establish these mappings using the addDataRoleMapping()
method.)
UsersRolesLoginModule
associates users with JAAS roles in plain text files.
Important
Chapter 3. Authentication Modules
3.1. Configuring Transports
security-domain
attribute within the transport
element is used to set a comma separated list of desired security domains (and their associated authentication modules).
<transport name="jdbc" protocol="teiid" socket-binding="teiid-jdbc"> <authentication security-domain="teiid-security"/> </transport>
username@domainname
3.2. Default File Based Authentication Module
<subsystem xmlns="urn:jboss:domain:security:1.2"> <security-domain name="teiid-security" cache-type="default"> <authentication> <login-module code="RealmDirect" flag="sufficient"> <module-option name="password-stacking" value="useFirstPass"/> </login-module> </authentication> </security-domain>
Note
<security-realm name="ApplicationRealm">
3.3. LDAP Based Authentication Module
LDAPExtended
authentication module defined for the ldap_security_domain
security domain.
<subsystem xmlns="urn:jboss:domain:security:1.2"> <security-domains> <security-domain name="ldap_security_domain"> <authentication> <login-module code="LdapExtended" flag="required"> <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory" /> <module-option name="java.naming.provider.url" value="ldap://mydomain.org:389" /> <module-option name="java.naming.security.authentication" value="simple" /> <module-option name="bindDN" value="myuser" /> <module-option name="bindCredential" value="mypasswd" /> <module-option name="baseCtxDN" value="ou=People,dc=XXXX,dc=ca" /> <module-option name="baseFilter" value="(cn={0})" /> <module-option name="rolesCtxDN" value="ou=Webapp-Roles,ou=Groups,dc=XXXX,dc=ca" /> <module-option name="roleFilter" value="(member={1})" /> <module-option name="uidAttributeID" value="member" /> <module-option name="roleAttributeID" value="cn" /> <module-option name="roleAttributeIsDN" value="true" /> <module-option name="roleNameAttributeID" value="cn" /> <module-option name="roleRecursion" value="-1" /> <module-option name="searchScope" value="ONELEVEL_SCOPE" /> <module-option name="allowEmptyPasswords" value="false" /> <module-option name="throwValidateError" value="true" /> </login-module> </authentication> </security-domain> </security-domains> </subsystem>
LDAPExtended
module, or any of the provided authentication modules, refer to the JBoss Enterprise Application Platform Security Guide.
Note
3.4. Role Mapping LoginModule
<subsystem xmlns="urn:jboss:domain:security:1.2"> <security-domains> <security-domain name="jdv_security_domain"> <authentication> ... <login-module code="org.jboss.security.auth.spi.RoleMappingLoginModule" flag="optional"> <module-option name="rolesProperties" value="${jboss.server.base.dir}/configuration/roles.properties" /> <module-option name="replaceRole" value="false" /> </login-module> ... </authentication> </security-domain> </security-domains> </subsystem>
3.5. Custom Authentication Modules
3.6. Example Custom Authentication Module
DatabaseServerLoginModule
module directly. You can provide a subclass:
public class MyLoginModule extends DatabaseServerLoginModule { protected String convertRawPassword(String password) { try { return new String((new sun.misc.BASE64Decoder()).decodeBuffer(password)); } catch (IOException e) { return password; } } }
<security-domain name="my-security-domain"> <authentication> <login-module code="com.mycompany.MyLoginModule" flag="required"> <module-option name="dsJndiName">java:MyDataSource</module-option> <module-option name="principalsQuery">select password from usertable where login=?</module-option> <module-option name="rolesQuery">select role, 'Roles' from users, userroles where login=? and users.roleId=userroles.roleId</module-option> </login-module> </authentication> </security-domain>
<transport name="jdbc" protocol="teiid" socket-binding="teiid-jdbc"> <authentication security-domain="my-security-domain"/> </transport>
Note
<dependency> <groupId>org.picketbox</groupId> <artifactId>picketbox</artifactId> <version>4.1.1.Final-redhat-1</version> <scope>provided</scope> </dependency>
3.7. Configure Pass-Through Authentication
Procedure 3.1. Configure Pass-Through Authentication
Set the security domain
Change the JBoss Data Virtualization security domain to the same name as your application's security domain name in thetransport
section of the server configuration file.
Note
PassthroughAuthentication=true
connection flag set.
Chapter 4. Authorization Modules
4.1. Custom Authorization Modules
org.teiid.PolicyDecider
can be installed via a JBoss module. This is a two-stage process: first you must create a jar that contains your custom class, then you must expose the jar as a JBoss module so it can be seen by all of your classes.
- Implement the org.teiid.PolicyDecider interface and build a custom java class. If you are using maven as your build process, you can use the following dependencies:
<dependencies> <dependency> <groupId>org.jboss.teiid</groupId> <artifactId>teiid-api</artifactId> <scope>provided</scope> </dependency> <dependency> <groupId>org.jboss.teiid</groupId> <artifactId>teiid-common-core</artifactId> <scope>provided</scope> </dependency> </dependencies>
- The PolicyDecider interface is loaded by JBoss Data Virtualization using Java's standard service loader mechanism. For this to work, add the
META-INF/services/org.teiid.PolicyDecider
file with the full name of your PolicyDecider implementation class as its contents. Here is an example:org.jboss.teiid.auth.MyCustomPolicyDecider
- Package all of these files into a JAR archive.
- Create a directory called
[JDV_HOME]/modules/com/mycompany/main/
. - Copy your jar file into the newly-created directory.
- Create a module.xml file and also put it in the
[JDV_HOME]/modules/com/mycompany/main/
directory.Here is an example that shows dependencies specific to JBoss Data Virtualization:<?xml version="1.0" encoding="UTF-8"?> <module xmlns="urn:jboss:module:1.0" name="com.mycompany"> <resources> <resource-root path="my_custom_policy.jar" /> <!--add any other dependent jars here, if they are not defined as modules --> </resources> <dependencies> <module name="org.jboss.teiid.common-core"/> <module name="org.jboss.teiid.api"/> <module name="javax.api"/> </dependencies> </module>
Note
If your PolicyDecider has any third-party dependencies, add them as dependencies to themodule.xml
file. Ensure you list all the files required. If dependencies are missing you will be informed when you start the software. - After the module has been added, edit the server configuration file (
standalone.xml
or its equivalent) to use your module name. The module must be added to the "teiid" subsystem:<policy-decider-module>MODULE-NAME</policy-decider-module>
- Restart the system.
Chapter 5. Configuring Transport Security
5.1. Transport Security Configuration
teiid
- By default, this only encrypts login traffic when none of the other configuration properties are used.odbc
- This default to "no SSL".odata
<transport name="jdbc" socket-binding="teiid-jdbc" protocol="teiid"> <authentication security-domain="teiid-security"/> </transport> <transport name="odbc" socket-binding="teiid-odbc" protocol="pg"> <authentication security-domain="teiid-security"/> <ssl mode="disabled"/> </transport>
<transport name="odata"> <authentication security-domain="teiid-security"/> </transport>
Note
pg
protocol for ODBC access uses cleartext username and password authentication by default. You should consider using a security domain that utilizes non-plaintext passwords, kerberos, or SSL.
5.2. Transport Security Properties
Table 5.1. SSL Properties
Setting | Description | Default Value |
---|---|---|
mode |
Options are:
disabled , login , or enabled .
If set to
disabled , no transport or message level encryption will be used.
If set to
login , only the login traffic will be encrypted at a message level using 128 bit AES with an ephemeral DH key exchange. This only applies to the teiid transport. (No other configuration values are required in this mode.)
If set to
enabled , traffic will be encrpyted using SSL according to the configuration properties below. teiid transport clients must connect using SSL with the mms protocol. ODBC pg transport clients may optionally use SSL.
| login |
keystore/name | The filename of the keystore that contains the private key of the server. The file name can be specified relative to the JBoss Data Virtualization deployer classloader or by absolute file system path. A typical installation would place the keystore file in the EAP_HOME/MODE/configuration directory. | cert.keystore |
keystore/password | The password used to access the keystore. | |
keystore/type | The keystore type created by the keytool. | JKS |
keystore/key-alias | The keystore key-alias created by the keytool. | |
ssl-protocol | Type of SSL protocol to be used. | TLSv1 |
keymanagement-algorithm | Type of key algorithm to be used. | |
truststore/name | If authentication-mode is set to 2-way , this property must be provided. This is the truststore that contains the public key for the client. Depending on how you created the keystore and truststores, this may be the same as the file specified for keystore/name . | cert.truststore |
truststore/password | The password used to access the truststore. | |
authentication-mode | Options are 1-way , 2-way and anonymous . | 1-way |
enabled-cipher-suites | A comma separated list of cipher suites allowed for encryption between the client and server. The values must be supported by the JVM, otherwise the SSL connections will fail.
Note
Both anonymous SSL and login only encryption are configured to use 128 bit AES encryption by default. By default, 1-way and 2-way SSL allow for cipher suite negotiation based upon the default cipher suites supported by the respective Java platforms of the client and server. Administrators can restrict the cipher suites used for encryption by setting the enabled-cipher-suites property.
| This defaults to all supported cipher suites for the virtual machine. |
Note
Warning
5.3. Transport Security Authentication Modes
anonymous
- No certificates are exchanged. Settings are not needed for the keystore and truststore properties. The client must have
org.teiid.ssl.allowAnon
set to true (the default) to connect to an anonymous server. Communications are encrypted using the TLS_DH_anon_WITH_AES_128_CBC_SHA SSL cipher suite. This is suitable for most secure intranets.Important
Anonymous SSL fails to work if you are using IBM's JDK. 1-way
- Athenticates the server to the client. The server presents a certificate which is signed by the private key stored in the server's keystore. The server's corresponding public key must be in the client's truststore.
2-way
- Mutual client and server authentication. The server presents a certificate which is signed by the private key stored in the server's keystore. The server's corresponding public key must be in the client's truststore. Additionally, the client presents a certificate signed by its private key stored in the client's keystore. The client's corresponsing public key must be in the server's truststore.
Note
See Also:
Chapter 6. Data Source Security
6.1. Data Source Security
- Authorization
- Any data source level authorization decisions are up to the source systems being integrated.
- Encryption
- Encrypting remote data source access is the responsibility for the resource adapter and library/driver used to access the source system.
- Translators
- The translator framework also provides hooks for securing access at the datasource level. ExecutionFactory.getConnection may be overridden to initialize the source connection in any number of ways, such as re-authentication, based upon the Subject, execution payload, session variables, and any of the other relevant information accessible via the ExecutionContext and the CommandContext. You may even also modify the generated source SQL in any way that is seen fit in the relevant Execution.
6.2. Authentication Modules for Data Source Security
- Caller Identity Login Module
- Role-Based Credential Map Identity Login Module
6.3. Caller Identity Login Module
CallerIdentityLoginModule
. Using this login module, users are able to supply to the data source the same credential used to log into the JBoss Data Virtualization security domain.
6.4. Configuring the Caller Identity Login Module
Procedure 6.1. Configure the Caller Identity Login Module
Create the Login Module
Configure authentication modules using the Management Console according to the following specification:<security-domain name="my-security-domain" cache-type="default"> <authentication> <login-module code="org.picketbox.datasource.security.CallerIdentityLoginModule" module="org.picketbox" flag="required"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="userName" value="guest"/> <module-option name="password" value="guest"/> </login-module> </authentication> </security-domain>
Configure the Data Source
Configure the datasource according to the following specification.<datasource jndi-name="java:/mysql-ds" pool-name="mysql-ds" enabled="true"> <connection-url>jdbc:mysql://localhost:3306/txns</connection-url> <driver>mysql</driver> <pool><allow-multiple-users/></pool> <security> <security-domain>my-security-domain</security-domain> </security> </datasource>
Configure the Connection Factory
Configure the resource adapter according to the following specification:<resource-adapter> <archive>teiid-connector-ldap.rar</archive> <transaction-support>NoTransaction</transaction-support> <connection-definitions> <connection-definition class-name="org.teiid.resource.adapter.ldap.LDAPManagedConnectionFactory" jndi-name="java:/ldapDS" enabled="true" use-java-context="true" pool-name="ldap-ds"> <config-property name="LdapUrl">ldap://ldapServer:389</config-property> <config-property name="LdapAdminUserDN">cn=???,ou=???,dc=???</config-property> <config-property name="LdapAdminUserPassword">pass</config-property> <config-property name="LdapTxnTimeoutInMillis">-1</config-property> <security> <security-domain>my-security-domain</security-domain> </security> </connection-definition> </connection-definitions> </resource-adapter>
When a user logs in with a password, the same password will also be set on the logged in Subject after authentication. These credentials can be extracted by the data source by asking for Subject's private credentials.
6.5. Role-Based Credential Map Identity Login Module
Warning
RoleBasedCredentialMap
for this purpose.
6.6. Configuring the Role-Based Credential Map Identity Login Module
Warning
Procedure 6.2. Configure Role-Based Credential Map Identity Login Module
Create the Login Module
Configure authentication modules using the Management Console according to the following specification:<subsystem xmlns="urn:jboss:domain:security:1.1"> <security-domains> <security-domain name="my-security-domain" cache-type="default"> <authentication> <login-module code="UsersRoles" flag="required"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="usersProperties" value="file://${jboss.server.config.dir}/teiid-security-users.properties"/> <module-option name="rolesProperties" value="file://${jboss.server.config.dir}/teiid-security-roles.properties"/> </login-module> <login-module code="org.teiid.jboss.RoleBasedCredentialMapIdentityLoginModule" flag="required"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="credentialMap" value="file://${jboss.server.config.dir}/teiid-credentialmap.properties"/> </login-module> </authentication> </security-domain> </security-domains> </subsystem>
Complete the Configuration
Configure the data source or connection factory in the same way as for theCallerIdentityLoginModule
.
In the above example, the primary login module UsersRolesLoginModule
is configured to login the primary user and assign some roles. The RoleBasedCredentialMap
login module is configured to hold role to password information in the file defined by the credentialMap
property. When the user logs in, the role information from the primary login module is taken, and the role's password is extracted and attached as a private credential to the Subject.
Note
credentialMap
property.
Chapter 7. Keytool
7.1. Keytool
7.2. Using Keytool with JBoss Data Virtualization
- Set the algorithm to
RSA
using the-keyslg RSA
option. - Set the store type to
JKS
using the-storetype JKS
option.
7.3. Create a Private/Public Key Pair with Keytool
Procedure 7.1. Create a Private/Public Key Pair with Keytool
- Run the
keytool -genkey -alias ALIAS -keyalg ALGORITHM -validity DAYS -keystore server.keystore -storetype TYPE
command:keytool -genkey -alias teiid -keyalg RSA -validity 365 -keystore server.keystore -storetype JKS
- If the specified keystore already exists, enter the existing password for that keystore, otherwise enter a new password:
Enter keystore password: <password>
- Answer the following questions when prompted:
What is your first and last name? [Unknown]: <user's name> What is the name of your organizational unit? [Unknown]: <department name> What is the name of your organization? [Unknown]: <company name> What is the name of your City or Locality? [Unknown]: <city name> What is the name of your State or Province? [Unknown]: <state name> What is the two-letter country code for this unit? [Unknown]: <country name>
- Enter
yes
to confirm the provided information is correct:Is CN=<user's name>, OU=<department name>, O="<company name>", L=<city name>, ST=<state name>, C=<country name> correct? [no]: yes
- Enter your desired keystore password:
Enter key password for <server> (Return if same as keystore password)
The server.keystore
file contains the newly generated public and private key pair.
7.4. Extract a Self-signed Certificate from the Keystore
Procedure 7.2. Extract a Self-signed Certificate from the Keystore
- Run the
keytool -export -alias ALIAS -keystore server.keystore -rfc -file public.cert
command:keytool -export -alias teiid -keystore server.keystore -rfc -file public.cert
- Enter the keystore password when prompted:
Enter keystore password: <password>
This creates the public.cert
file that contains a certificate signed with the private key in the server.keystore
.
7.5. Add a Certificate to a Truststore Using Keytool
Procedure 7.3. Add a Certificate to a Truststore Using Keytool
- Run the
keytool -import -alias ALIAS -file public.cert -storetype TYPE -keystore server.truststore
command:keytool -import -alias teiid -file public.cert -storetype JKS -keystore server.truststore
- If the specified truststore already exists, enter the existing password for that truststore, otherwise enter a new password:
Enter keystore password: <password>
- Enter
yes
when prompted to trust the certificate:Owner: CN=<user's name>, OU=<dept name>, O=<company name>, L=<city>, ST=<state>, C=<country> Issuer: CN=<user's name>, OU=<dept name>, O=<company name>, L=<city>, ST=<state>, C=<country> Serial number: 416d8636 Valid from: Fri Jul 31 14:47:02 CDT 2009 until: Sat Jul 31 14:47:02 CDT 2010 Certificate fingerprints: MD5: 22:4C:A4:9D:2E:C8:CA:E8:81:5D:81:35:A1:84:78:2F SHA1: 05:FE:43:CC:EA:39:DC:1C:1E:40:26:45:B7:12:1C:B9:22:1E:64:63 Trust this certificate? [no]: yes
The certificate in public.cert
has been added to the new truststore named server.truststore
.
Chapter 8. Kerberos Support Through GSS API
8.1. Kerberos and Red Hat JBoss Data Virtualization
8.1.1. Introduction to Kerberos Authentication on Red Hat JBoss Data Virtualization
8.1.1.1. Local Connection Overview
8.1.1.2. Remote Connections (JDBC/ODBC)
Note
<security-domain name="host"> <authentication> <login-module code="Kerberos" flag="required"> <module-option name="storeKey" value="true"/> <module-option name="useKeyTab" value="true"/> <module-option name="principal" value="host/testserver@MY_REALM"/> <!-- service principal --> <module-option name="keyTab" value="/path/to/service.keytab"/> <module-option name="doNotPrompt" value="true"/> <module-option name="debug" value="false"/> </login-module> </authentication> </security-domain>
Note
<security-domain name="MY_REALM"> <authentication> <!-- Check the username and password --> <login-module code="SPNEGO" flag="requisite"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="serverSecurityDomain" value="host"/> </login-module> <!-- Search for roles --> <login-module code="UserRoles" flag="requisite"> <module-option name="password-stacking" value="useFirstPass" /> <module-option name="usersProperties" value="spnego-users.properties" /> <module-option name="rolesProperties" value="spnego-roles.properties" /> </login-module> </authentication> </security-domain>
8.1.1.3. User Roles and Groups
<module-option name="usernamePasswordDomain" value="{user-name-based-auth}"/>
<transport name="jdbc" protocol="teiid" socket-binding="teiid-jdbc"/> <authentication security-domain="MY_REALM" type="GSS"/> </transport>
<transport name="odbc" protocol="pg" socket-binding="teiid-odbc"/> <authentication security-domain="MY_REALM" type="GSS"/> </transport>
Table 8.1. Type Values
Value | Description |
---|---|
USERPASSWORD | This only allows you to create username and password-based authentication. |
GSS | This allows you to create GSS API-based authentications using Kerberos5. |
<property name="security-domain" value="MY_REALM" /> <property name="gss-pattern" value="{regex}" /> <property name="password-pattern" value="{regex}" /> <property name="authentication-type" value="GSS or USERPASSWORD" />
Table 8.2. Table Properties
Property | Description |
---|---|
security-domain | Use this to define VDB-based security. |
authentication-type | This allows you to enforce single authentication. |
gss-pattern | This allows you to use GSS. |
password-pattern | This allows you to use USERPASSWORD. |
<property name="security-domain" value="MY_REALM" /> <property name="gss-pattern" value="logasgss" />
<property name="security-domain" value="MY_REALM" /> <property name="authentication-type" value="GSS" />
JAVA_OPTS = "$JAVA_OPTS -Djava.security.krb5.realm=EXAMPLE.COM -Djava.security.krb5.kdc=kerberos.example.com -Djavax.security.auth.useSubjectCredsOnly=false"
JAVA_OPTS = "$JAVA_OPTS -Djava.security.krb5.conf=/path/to/krb5.conf -Djava.security.krb5.debug=false -Djavax.security.auth.useSubjectCredsOnly=false"
<system-properties> <property name="java.security.krb5.conf" value="/pth/to/krb5.conf"/> <property name="java.security.krb5.debug" value="false"/> <property name="javax.security.auth.useSubjectCredsOnly" value="false"/> </system-properties>
8.1.1.4. JDBC Client Configuration
Teiid { com.sun.security.auth.module.Krb5LoginModule required useTicketCache=true storeKey=true useKeyTab=true keyTab="/path/to/krb5.keytab" doNotPrompt=true debug=false principal="user@EXAMPLE.COM"; };
-Djava.security.krb5.conf=/path/to/krb5.conf -Djava.security.auth.login.config=/path/to/client.conf -Djavax.security.auth.useSubjectCredsOnly=false -Dsun.security.krb5.debug=false
-Djava.security.krb5.realm=EXAMPLE.COM -Djava.security.krb5.kdc=kerberos.example.com -Djavax.security.auth.useSubjectCredsOnly=false -Dsun.security.krb5.debug=false -Djava.security.auth.login.config=/path/to/client.conf
jaasName=Teiid;user={pattern};kerberosServicePrincipleName=host/testserver@MY_REALM
Note
Table 8.3. Properties
Value | Description |
---|---|
jaasName | This defines the JAAS configuration name in the client.conf file's java.security.auth.login.config property. This property is optional. If it is omitted, "Teiid" is used by default. |
kerberosServicePrincipleName | This defines service principle that is requested on behalf of the service to which you are connecting. If this property is omitted, the default principle used is TEIID/hostname" and hostname is derived from the JDBC connection URL. |
8.1.1.5. ODBC Client Configuration
8.1.1.6. OData Client
mvn clean install
Chapter 9. OAuth2-Based Security for OData
9.1. OAuth2-Based Security for OData
9.1.1. Configuring Your Red Hat SSO Server
You must have Red Hat SSO installed as a separate web server, preferably on a different server machine.
- Go to http://localhost:8080/auth/admin/master/console/#/realms/oauth and use the default admin/admin credentials. (You may have to create a Red Hat SSO administrative account in order to do this.)
- Under the General tab, add a new realm called oauth-demo.
- Under Manage -> Users, click Add User and add a new user called user with credentials.
- Under Configure - Roles - Realm, click Add Roles and add the odata and user roles to your new user.
- Under Configure - Clients - Settings, add a new client called odata4-oauth. Add the odata and user roles and then choose scopes odata and user for this client.
Note
The redirect URI needs to be where the actual service is going to be available. Here is an example: http://[host]:[port]/odata4/*The client web-service defines the roles the logged-in user must have in order to be granted access. In the Red Hat SSO OAuth2 implementation, these roles are used as scopes. Note that the odata4-oauth client must have the scopes that it is going to delegate the access-token for gaining access to bottom data services. In this example Red Hat JBoss Data Virtualization’s OData web services requires the odata role. If you are delegating the access-token to the underlying web-service requires the user role.Note
The user role is suggested as an example role required for the underlying source webservice. You need to replace it with the real role required for the webservice.
9.1.2. Configure the Red Hat JBoss Data Virtualization server
Red Hat JBoss Data Virtualization server installed.
- Follow the instructions found here in the Red Hat SSO documentation to install the EAP 6 adapter: https://access.redhat.com/documentation/en/red-hat-single-sign-on/7.0/paged/securing-applications-and-services-guide/chapter-2-openid-connect
- Run this script to change the OData transport’s security-domain section:
./bin/jboss-cli.sh --connect /subsystem=teiid/transport=odata:write-attribute(name=authentication-security-domain, value=keycloak) reload
The code will change to look like this:<transport name="odata"> <authentication security-domain="keycloak"/> </transport>
Note that, for this to deploy, you must also have the security domain configured on the server. To do so, run these commands to create Oauth and Keycloak security domains:/subsystem=security/security-domain=oauth:add(cache-type=default) /subsystem=security/security-domain=oauth/authentication=classic:add /subsystem=security/security-domain=oauth/authentication=classic/login-module=oauth:add(code=org.teiid.jboss.PassthroughIdentityLoginModule, flag=required, module=org.jboss.teiid) /subsystem=security/security-domain=keycloak:add(cache-type=default) /subsystem=security/security-domain=keycloak/authentication=classic:add /subsystem=security/security-domain=keycloak/authentication=classic/login-module=keycloak:add(code=org.keycloak.adapters.jboss.KeycloakLoginModule, flag=required) reload
- Undeploy the WAR file:
undeploy teiid-olingo-odata4.war
- Download the Maven project found here: https://github.com/teiid/teiid-web-security
- Replace the
teiid-web-security/teiid-odata-oauth-keycloak/src/main/webapp/WEB-INF/keyclock.json
file’s contents with theinstallation
script from the Red Hat SSO admin console’s odata4-client application. - Edit the
teiid-web-security/odata-oauth-keycloak/src/main/webapp/WEB-INF/web.xml
file to enable passthrough authentication:<init-param> <param-name>PassthroughAuthentication</param-name> <param-value>true</param-value> </init-param>
- Use Maven to build the WAR file.
- Deploy the WAR file using this script:
deploy PATH/teiid-olingo-odata4.war
- Go here to test: http://localhost:8180/odata4/keycloak/auth
Note
Note
curl -v POST http://localhost:8080/auth/realms/oauth-demo/protocol/openid-connect/token -H Content-Type: application/x-www-form-urlencoded -d 'username=user' -d 'password=user' -d 'grant_type=password' -d 'client_id=odata4-oauth' -d 'client_secret=36fdc2b9-d2d3-48df-8eea-99c0e729f525'
{ "access_token":"eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI0YjI4NDMzYS1.." , "expires_in":300, "refresh_expires_in":1800, "refresh_token":"eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJmY2JmNjY2ZC0xNzIwLTQwODQtOTBiMi0wMjg4ODdhNDkyZWYiLCJl..", "token_type":"bearer", "id_token":"eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiIwZjYyNDQ1MS1iNTE0LTQ5YjUtODZlNy1jNTI5MDU2OTI3ZDIiLCJleH..", "not-before-policy":0, "session-state":"6c8884e8-c5aa-4f7a-a3fe-9a7f6c32658c" }
curl -k -H "Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI0YjI4NDMzYS1.." http://localhost:8180/odata4/oauthdemo/view/message
9.1.3. Delegation of an OAuth2 Token to a Data Source
- Log into the RH-SSO admin console.
- Under the realm oauth-demo, and then Clients -> Settings, add another client called database-service and set the scope to user. Set the type to Bearer.
- Follow the instructions in RH-SSO to secure this web service with above realm oauth-demo
- Deploy this WAR into your web server.
- Create a web service resource adapter for this service, using oauth as the security-domain.
- Use this resource adapter as source in developing your virtual database.
Note
The delegation will occur if the virtual database is accessed through the OData interface. JDBC-based access to this virtual database would fail.
Chapter 10. Patch Installation
10.1. Subscribe to Patch Mailing Lists
The JBoss team at Red Hat maintains a mailing list for security announcements for Red Hat JBoss Enterprise Middleware products. This topic covers what you need to do to subscribe to this list.
Prerequisites
- None
Procedure 10.1. Subscribe to the JBoss Watch List
- Click the following link to go to the JBoss Watch mailing list page: JBoss Watch Mailing List.
- Enter your email address in the Subscribing to Jboss-watch-list section.
- [You may also wish to enter your name and select a password. Doing so is optional but recommended.]
- Press the Subscribe button to start the subscription process.
- You can browse the archives of the mailing list by going to: JBoss Watch Mailing List Archives.
After confirmation of your email address, you will be subscribed to receive security related announcements from the JBoss patch mailing list.
10.2. Patching Process
Important
Procedure 10.2. Upgrading
- Ensure the server is shut down.
- To update to the latest version contained in the jar’s repository, run these commands:
$ java -jar /path/to/jboss-dv-6.4.x-patch.jar --server some-server/ --query-server jboss-dv-6.4.x $ java -jar /path/to/jboss-dv-6.4.x-patch.jar --server some-server/ --update jboss-dv INFO - Upgrade from jboss-dv-6.4.0 to jboss-dv-6.4.x
Alternatively, you can manually specify the version using these commands:$ java -jar /path/to/jboss-dv-6.4.x-patch.jar --server some-server/ --query-server jboss-dv-6.4.0 $ java -jar /path/to/jboss-dv-6.4.x-patch.jar --server some-server/ --install jboss-dv-6.4.x INFO - Upgrade from jboss-dv-6.4.0 to jboss-dv-6.4.x
Note
The --server argument is optional. If it is not specified, the JBOSS_HOME environment variable, and then the current/working directory will be tried. A basic test will be undertaken to make sure the directory appears to be the server root, otherwise an error will be returned.
Procedure 10.3. Downgrading
- Ensure the server is shut down.
- Roll back by specifying a version lower than the current version as the install argument’s value:
$ java -jar /path/to/jboss-dv-6.4.x-patch.jar --server some-server/ --query-server jboss-dv-6.4.x $ java -jar /path/to/jboss-dv-6.4.x-patch.jar --server some-server/ --install jboss-dv-6.4.0 INFO - Downgrade from jboss-dv-6.4.x to jboss-dv-6.4.0
$ java -jar [path]/64-patching/jboss-dv-6.4.x-patch.jar --server dist/ --update jboss-dv INFO - Upgrade from jboss-dv-6.4.0 to jboss-dv-6.4.x ERROR - Attempt to override an already modified file dataVirtualization/vdb/teiid-odata.war ERROR - Attempt to override an already modified file modules/system/layers/dv/org/jboss/teiid/api/main/teiid-api-8.12.5.redhat-7.jar ERROR - ERROR One or more checksum failures, aborting operation. Use --force to override.
$ java -jar [path]/63-patching/jboss-dv-6.4.x-patch.jar --server dist/ --update jboss-dv --force INFO - Upgrade from jboss-dv-6.4.0 to jboss-dv-6.4.x WARN - Overriding an already modified file: dataVirtualization/vdb/teiid-odata.war WARN - Overriding an already modified file: modules/system/layers/dv/org/jboss/teiid/api/main/teiid-api-8.12.5.redhat-7.jar
Warning
$ java -jar /path/to/jboss-dv-6.4.x-patch.jar --query-repository jboss-dv-6.4.0 jboss-dv-6.4.x
$ java -jar /path/to/jboss-dv-6.4.x-patch.jar --server some-server/ --query-server jboss-dv-6.4.x
$ java -jar [path]/jboss-dv-6.4.x-patch.jar --server dist/ --query-server-paths cli-scripts/ cli-scripts/ModeShape-domain.cli [jboss-dv-6.4.0] cli-scripts/ModeShape-standalone.cli [jboss-dv-6.4.0] cli-scripts/disable-welcome-root-domain.cli [jboss-dv-6.4.0] cli-scripts/disable-welcome-root.cli [jboss-dv-6.4.0] cli-scripts/teiid-add-database-logger-domain.cli [jboss-dv-6.4.0] cli-scripts/teiid-add-database-logger.cli [jboss-dv-6.4.0] cli-scripts/teiid-dashboard-add_datasource.cli [jboss-dv-6.4.0] cli-scripts/teiid-dashboard-domain-add_datasource.cli [jboss-dv-6.4.0] cli-scripts/teiid-deploy-dashboard-domain.cli [jboss-dv-6.4.0] cli-scripts/teiid-deploy-dashboard.cli [jboss-dv-6.4.0] cli-scripts/teiid-domain-auditcommand-logging.cli [jboss-dv-6.4.0] cli-scripts/teiid-domain-mode-install.cli [jboss-dv-6.4.0] cli-scripts/teiid-logger-ds.properties [jboss-dv-6.4.0] cli-scripts/teiid-modeshape-domain.cli [jboss-dv-6.4.0] cli-scripts/teiid-modeshape-standalone.cli [jboss-dv-6.4.0] cli-scripts/teiid-standalone-auditcommand-logging.cli [jboss-dv-6.4.0] cli-scripts/teiid-standalone-mode-install.cli [jboss-dv-6.4.0]
$ java -jar /path/to/jboss-dv-6.4.x-patch.jar --server some-server/ --audit-log # 13-Jul-2016 14:23:42 # Upgrade from jboss-dv-6.4.0 to jboss-dv-6.4.x [properties] [content] ADD dataVirtualization/jdbc/modeshape-client-3.8.4.GA-redhat-8.jar 3027790150 DEL dataVirtualization/jdbc/modeshape-client-3.8.4.GA-redhat-9.jar 692252461 ADD dataVirtualization/jdbc/teiid-8.12.5.redhat-6-jdbc.jar 2751767369 DEL dataVirtualization/jdbc/teiid-8.12.5.redhat-7-jdbc.jar 181512329 ADD dataVirtualization/jdbc/teiid-hibernate-dialect-8.12.5.redhat-6.jar 2332531122 DEL dataVirtualization/jdbc/teiid-hibernate-dialect-8.12.5.redhat-7.jar 351948893 UPD dataVirtualization/logging/database-service.jar 2354483517 ... # 13-Jul-2016 14:25:18 # Downgrade from jboss-dv-6.4.x to jboss-dv-6.4.0 [properties] [content] DEL dataVirtualization/jdbc/modeshape-client-3.8.4.GA-redhat-8.jar 3027790150 ADD dataVirtualization/jdbc/modeshape-client-3.8.4.GA-redhat-9.jar 692252461 DEL dataVirtualization/jdbc/teiid-8.12.5.redhat-6-jdbc.jar 2751767369 ADD dataVirtualization/jdbc/teiid-8.12.5.redhat-7-jdbc.jar 181512329 DEL dataVirtualization/jdbc/teiid-hibernate-dialect-8.12.5.redhat-6.jar 2332531122 ADD dataVirtualization/jdbc/teiid-hibernate-dialect-8.12.5.redhat-7.jar 351948893 UPD dataVirtualization/logging/database-service.jar 3678296797 ...
10.3. Severity and Impact Rating of JBoss Security Patches
Table 10.1. Severity Ratings of JBoss Security Patches
Severity | Description |
---|---|
Critical |
This rating is given to flaws that could be easily exploited by a remote unauthenticated attacker and lead to system compromise (arbitrary code execution) without requiring user interaction. These are the types of vulnerabilities that can be exploited by worms. Flaws that require an authenticated remote user, a local user, or an unlikely configuration are not classed as critical impact.
|
Important |
This rating is given to flaws that can easily compromise the confidentiality, integrity, or availability of resources. These are the types of vulnerabilities that allow local users to gain privileges, allow unauthenticated remote users to view resources that should otherwise be protected by authentication, allow authenticated remote users to execute arbitrary code, or allow local or remote users to cause a denial of service.
|
Moderate |
This rating is given to flaws that may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances. These are the types of vulnerabilities that could have had a critical impact or important impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.
|
Low |
This rating is given to all other issues that have a security impact. These are the types of vulnerabilities that are believed to require unlikely circumstances to be able to be exploited, or where a successful exploit would give minimal consequences.
|
Example 10.1. CVSS v2 Impact Score
C:N/I:P/A:C
Appendix A. Revision History
Revision History | |||
---|---|---|---|
Revision 6.4.0-11 | Fri Jun 07 2017 | David Le Sage | |
|