JBoss.orgCommunity Documentation
The Teiid system provides a range of built-in and extensible security features to enable the secure access of data.
JDBC clients may use simple passwords to authenticate a user.
Typically a user name is required, however user names may be considered optional if the identity of the user can be discerned by the password credential alone. In any case it is up to the configured security domain to determine whether a user can be authenticated. If you need authentication, the administrator must configure a LoginModule to be used with Teiid. See below for more information on how configure the Login module in JBoss AS.
By default, access to Teiid is NOT secure. The default login modules are only backed by file based authentication, which has a well known user name and password. The same is true for making connections to the Admin Console application. We DO NOT recommend leaving the default security profile as defined when you are exposing sensitive data.
If your client application (web application or Web service) resides in the same JBoss AS instance as Teiid and the client application uses a security-domain, then you can configure Teiid to use the same security-domain and not force the user to re-authenticate. In this case Teiid looks for an authenticated subject in the calling thread context and uses it for sessioning and authorization. To configure Teiid for pass-through authentication, change the Teiid security-domain name to the same name as your application's security domain name in the "teiid-jboss-beans.xml" file in the SessionService section. Please note that for this to work, the security-domain must be a JAAS based Login Module and your client application MUST obtain its Teiid connection using a local/embedded connection with thePassthroughAuthentication=true connection flag set.
Authorization covers both administrative activities and data roles. A data role is a collection of permissions (also referred to as entitlements) and a collection of entitled principals or groups. With the deployment of a VDB the deployer can choose which principals and groups have which data roles.
At a transport level Teiid provides built-in support for JDBC over SSL or just sensitive message encryption when SSL is not in use.
Passwords in configuration files however are by default stored in plain text. If you need these values to be encrypted, please see encrypting passwords for instructions on encryption facilities provided by the container.
LoginModules are an essential part of the JAAS security framework and provide Teiid customizable user authentication and the ability to reuse existing LoginModules defined for JBossAS. See JBossAS Security for general information on configuring security in JBossAS.
Teiid can be configured with multiple named application policies
that group together relevant LoginModules. Each of these application
policy (or domain) names can be used to fully qualify user names to
authenticate only against that domain. The format for a qualified
name is username@domainname. The securityDomains property under the SessionService bean in <jboss-install>/server/<profile>/deploy/teiid/teiid-jboss-beans.xml should be used set
the comma separated list of desired domains. The securityDomains property defaults to a single domain named teiid-security.
The domain for admin access may also be changed if desired via the adminSecurityDomain property, however it is expected that the admin
domain will be the same one that is used by the AS profile service, which by default is named jmx-console.
If a user name is not fully qualified, then the installed domains will be consulted in order until a domain successfully or unsuccessfully authenticates the user.
If no domain can authenticate the user, the login attempt will fail. Details of the failed attempt including invalid users, which domains were consulted, etc. will be in the server log with appropriate levels of severity.
The security-domain defined for the JDBC connection and Admin connections are separate. The default name of JDBC connection's security-domain is "teiid-security". The default name for Admin connection is "jmx-console". For the Admin connection's security domain, the user is allowed to change which LoginModule that "jmx-console" pointing to, however should not change the name of the domain, as this name is shared between the "admin-console" application. In existing installations an appropriate security domain may already be configured for use by administrative clients (typically "jmx-console"). In this case it may be perfectly valid to reuse this existing security domain instead of creating a new teiid-security security domain.
JBossAS provides several LoginModules for common authentication needs, such as authenticating from a Section 3.4.1.1, “Text Based LoginModule” or a Section 3.4.1.2, “LDAP Based LoginModule”.
You can install multiple login modules as part of single security domain configuration and configure them to part of login process. For example, for "teiid-security" domain, you can configure a file based and also LDAP based login modules, and have your user authenticated with either or both login modules. If you want to write your own custom login module, refer to the Developer's Guide for instructions.
The UsersRolesLoginModule utilizes simple text files to authenticate users and to define their groups. The teiid-jboss-beans.xml configuration file contains an example of how to use UsersRolesLoginModule.
The UsersRolesLoginModule is not recommended for production use and it is strongly recommended that you replace this login module.
User names and passwords are stored in the <profile>conf/props/teiid-security-users.properties file.
Example 3.1. Example user.properties file
# A users.properties file for use with the UsersRolesLoginModule # username=password fred=password george=password ...
JAAS role assignments are stored in the <profile>conf/props/teiid-security-roles.properties file.
Example 3.2. Example user.properties file
# A roles.properties file for use with the UsersRolesLoginModule # username=role1,role2,... data_role_1=fred,sally data_role_2=george
User and role names are entirely up to the needs of the given deployment. For example each application team can set their own security constraints for their VDBs, by mapping their VDB data roles to application specific JAAS roles, e.g. app_role_1=user1,user2,user3.
Teiid data roles names are independent of JAAS roles. VDB creators can choose whatever name they want for their data roles, which are then mapped at deployment time to JAAS roles.
See LDAP LoginModule configuration for the AS community guide. The following are streamlined installation instruction.
If using SSL to the LDAP server, ensure that the Corporate CA Certificate is added to the JRE trust store.
Include LDAP LoginModule in the JAAS Configuration
Configure LDAP authentication by editing <profile>conf/login-config.xml. If you wish to configure specifically for teiid, then the security domain teiid-security will need to be created/altered. In new installations the more likely option is that you want to configure LDAP based authentication for the AS itself by modifying the "jmx-console" security domain. You could do one of the following for Teiid:
Reuse the jmx-console (or whatever name you choose) security domain for Teiid by changing the Teiid configuration <jboss-install>/server/<profile>/deploy/teiid/teiid-jboss-beans.xml to point to jmx-console, rather than teiid-security.
Follow the same steps to configure an LDAP security domain named teiid-security.
Leave Teiid to use the default file based LoginModule secuirty domain or create an entirely custom security domain configuration.
Obscure the LDAP Password
Finally, protect the password following these instructions. Note that the salt must be 8 chars and see also http://community.jboss.org/message/137756#137756 for more on securing passwords.
Teiid supports kerberos authentication using GSSAPI, to be used with single sign-on applications. This service ticket negotiation based authentication is supported through remote JDBC and ODBC drivers and LocalConnections. Client configuration is different for all connection types.
Set the JDBC URL property PassthroughAuthentication as true and use JBoss Negotiation for authentication of your web-application with kerberos. When the web application authenticates with the provided kerberos token, the same subject authenticated will be used in Teiid. For details about configuration, check the JBoss Negotiation documentation.
On the server, edit the <jboss-install>/server/<profile>/deploy/teiid/teiid-jboss-beans.xml under the "SessionService" bean definition, as follows:
<!-- Sets the authentication Type --> <property name="authenticationType">GSS</property> <!-- Security domain used for kerberos authentication --> <property name="gssSecurityDomain">teiid-krb5</property>
Now we need to define a security domain context for kerberos with the name mentioned in above. Since kerberos authorization cannot define authorization roles, we'll define them using another login context. Given below is a sample configuration to define roles using a UserRolesLoginModule.
This configuration replaces the default Teiid login configuration, and you should change the principal and key tab locations accordingly.
<!--login module that negotiates the login conext for kerberos -->
<application-policy xmlns="urn:jboss:security-beans:1.0" name="teiid-krb5">
<authentication>
<login-module code="com.sun.security.auth.module.Krb5LoginModule" flag="required">
<module-option name="storeKey">true</module-option>
<module-option name="useKeyTab">true</module-option>
<module-option name="principal">demo@EXAMPLE.COM</module-option>
<module-option name="keyTab">path/to/krb5.keytab</module-option>
<module-option name="doNotPrompt">true</module-option>
<module-option name="debug">false</module-option>
</login-module>
</authentication>
</application-policy>
<!-- teiid's default security domain, replace this with your own if needs to be any other JAAS domain -->
<application-policy xmlns="urn:jboss:security-beans:1.0" name="teiid-security">
<authentication>
<!-- This module assosiates kerberos user with this login set of login modules -->
<login-module code="org.teiid.jboss.AssosiateCallerIdentityLoginModule" flag="required"/>
<!-- Login module used for defining roles for user authencated using kerberos, keep the users file empty
but provide roles in the roles file for users -->
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
<module-option name="password-stacking">useFirstPass</module-option>
<module-option name="usersProperties">props/teiid-security-users.properties</module-option>
<module-option name="rolesProperties">props/teiid-security-roles.properties</module-option>
</login-module>
</authentication>
</application-policy>Edit the "run.conf" or "run.conf.bat" file depending upon the environment in the "${jboss-as}/bin" directory and add the following JVM options (changing the realm and KDC settings according to your environment)
JAVA_OPTS = "$JAVA_OPTS -Djava.security.krb5.realm=EXAMPLE.COM -Djava.security.krb5.kdc=kerberos.example.com -Djavax.security.auth.useSubjectCredsOnly=false"
This finishes the configuration on the server side, restart the server and make sure that there were no errors during startup.
In you client VM the JAAS configuration for kerberos authentication needs to be written. A sample configuration file (client.conf) is show below
Client {
com.sun.security.auth.module.Krb5LoginModule required
useTicketCache=true
storeKey=true
useKeyTab=true
keyTab="/path/to/krb5.keytab"
doNotPrompt=false
debug=false
principal="demo@EXAMPLE.COM";
};Add the following JVM options to your client's startup script - change Realm and KDC settings according to your environment
-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
Add the following URL connection properties to Teiid JDBC connection string
authenticationType=KRB5;jaasName=Client;kerberosServicePrincipleName=demo@EXAMPLE.COM
There is no need to provide the user name and password. When the application makes a JDBC connection, it will authenticate locally and use the same user credentials to negotiate a service token with server and grant the connection. See Client Developer's guide for information on connection properties and how to configure data sources.
In some use cases, the user might need to pass-in different credentials to their data sources based on the logged in user rather than using the shared credentials for all the logged users. To support this feature, JBoss AS and Teiid provide multiple different login modules to be used in conjunction with Teiid's main security domain. See this document for details on configuration. Note that the below directions need to be used in conjunction with this document.
If client wants to pass in simple text password or a certificate or a custom serialized object as token credential to the data source, user can configure "CallerIdentity" login module. Using this login module, user can pass-in same credential that user logged into Teiid security domain to the data source. Here is a sample configuration, this needs to be configured in "teiid-jboss-beans.xml" file.
<application-policy xmlns="urn:jboss:security-beans:1.0" name="teiid-security">
<authentication>
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
<module-option name = "password-stacking">useFirstPass</module-option>
<module-option name="usersProperties">props/teiid-security-users.properties</module-option>
<module-option name="rolesProperties">props/teiid-security-roles.properties</module-option>
</login-module>
<login-module code="org.jboss.resource.security.CallerIdentityLoginModule" flag="required">
<module-option name = "password-stacking">useFirstPass</module-option>
<module-option name = "managedConnectionFactoryName">jboss.jca:service=LocalTxCM,name=DefaultDS</module-option>
</login-module>
</authentication>
</application-policy>In the -ds.xml file that is defined as the "managedConnectionFactoryName" in the above configuration, you need to add the following element
<security-domain>teiid-security</security-domain>
In the above configuration example, in the primary login module "UsersRolesLoginModule" is set up to hold the passwords in the file, and when user logs in with password, the same password will be also set on the logged in Subject after authentication. These credentials can be extracted by the data source by asking for Subject's private credentials.
To use a certificate or serialized object instead of plain password as the token, replace the simple text password with Base64 encoded contents of the serialized object. Please note that encoding and decoding of this object is strictly up to the user as JBoss AS and Teiid will only act as a carrier of the information from login module to connection factory. Using this CallerIdentity module, the connection pool for data source is segmented by Subject.
In some use cases, the users are divided by their functionality and they have varied levels of security access to data sources. These types of users are identified by their roles as to what they have access to. In the above "CallerIdentity" login scenario, that may be too fine-grained security at data sources, that can lead resource exhaustion as every user has their own separate connection. Using Role based security gives a balance, where the users with same role are treated equally for authentication purposes at the data source. Teiid provides a login module called "RoleBasedCredentialMap" for this purposes, where administrator can define a role-based authentication module, where given the role of the user from the primary login module, this module will hold a credential to that role. So, it is the container of credentials that maps to different roles. If a user has multiple roles, the first role that has the credential will be chosen. Below find the sample configuration.
<application-policy xmlns="urn:jboss:security-beans:1.0" name="teiid-security">
<authentication>
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
<module-option name = "password-stacking">useFirstPass</module-option>
<module-option name="usersProperties">props/teiid-security-users.properties</module-option>
<module-option name="rolesProperties">props/teiid-security-roles.properties</module-option>
</login-module>
<login-module code="org.teiid.jboss.RoleBasedCredentialMapIdentityLoginModule" flag="required">
<module-option name = "password-stacking">useFirstPass</module-option>
<module-option name="credentialMap">props/teiid-credentialmap.properties</module-option>
<module-option name = "managedConnectionFactoryName">jboss.jca:service=LocalTxCM,name=DefaultDS</module-option>
</login-module>
</authentication>
</application-policy>In the -ds.xml file that is defined as the "managedConnectionFactoryName" in the above configuration, you need to add the following element
<security-domain>teiid-security</security-domain>
In the above configuration example, in the primary login module "UsersRolesLoginModule" is set up for logging in the primary user and assign some roles. The "RoleBasedCredentialMap" login module is configured to hold role to password information in the file defined by "credentialMap" property. When user logs in, the role information from the primary login module is taken, and extracts the role's passsword and attaches as a private credential to the Subject. If you want use this for role based trusted token, you can configure the Base64 based endcoding/decoded object as defined above.
You can also encrypt the password instead of plain text password using this module. Just include the encrypted password in the file defined by the "credentialMap" property, and define following properties in the "RoleBasedCredentialMap" login module.
<login-module code="org.teiid.jboss.RoleBasedCredentialMapIdentityLoginModule" flag="required">
<module-option name = "password-stacking">useFirstPass</module-option>
<module-option name="credentialMap">props/teiid-credentialmap.properties</module-option>
<module-option name = "managedConnectionFactoryName">jboss.jca:service=LocalTxCM,name=DefaultDS</module-option>
<!-- below properties are only required when passwords are encrypted -->
<module-option name = "pbealgo">PBEWithMD5AndDES</module-option>
<module-option name = "pbepass">testPBEIdentityLoginModule</module-option>
<module-option name = "salt">abcdefgh</module-option>
<module-option name = "iterationCount">19</module-option>
</login-module>For full details about encryption of the password, please follow this document's "A KeyStore based login module for encrypting a datasource password" section. Be sure to give the same configuration elements in the above configuration, as they are used to encrypt the password.
The Teiid's configuration file
<jboss-install>/server/<profile>/deploy/teiid/teiid-jboss-beans.xml,
contains the properties to configure SSL per socket transport.
There are three socket transports, each with its own SSL configuration:
JDBC Connections - uses the JdbcSslConfiguration bean configuration. Defaults to only encrypt login traffic, none of the other properties are used.
Admin Connections - uses the AdminSslConfiguration bean configuration. Defaults to encrypting all traffic with anonymous SSL, none of the other properties are used.
ODBC Connections - uses the OdbcSslConfiguration bean configuration. Defaults to no SSL.
Example 3.3. Example Configuration
<bean name="JdbcSslConfiguration" class="org.teiid.transport.SSLConfiguration">
<property name="mode">login</property>
<property name="keystoreFilename">cert.keystore</property>
<property name="keystorePassword">passwd</property>
<property name="keystoreType">JKS</property>
<property name="sslProtocol">SSLv3</property>
<property name="keymanagementAlgorithm">false</property>
<property name="truststoreFilename">cert.truststore</property>
<property name="truststorePassword">passwd</property>
<!-- 1-way, 2-way, anonymous -->
<property name="authenticationMode">1-way</property>
<!-- an optional property to constrain the cipher suites to be negotiated between server and client -->
<property name="enabledCipherSuites">SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA</property>
</bean>Properties
mode - diabled|login|enabled, disabled = no transport or message level security will be used. login = only the login traffic will be encrypted at a message level using 128 bit AES with an ephemerial DH key exchange. No other config values are needed in this mode. enabled = traffic will be secured using the other configuration properties.
sslProtocol- Type of SSL protocol to be used. Default is TLSv1
keystoreType - Keystore type created by the keytool. Default "JKS" is used.
authenticationMode - anonymous|1-way|2-way, Type of SSL Authentication Mode.
keymanagementAlgorithm - Type of key algorithm used. Default is based upon the VM, e.g. "SunX509"
keystoreFilename - The file name of the keystore, which contains the private key of the Server. The file name can be relative resource path available to the Teiid deployer classloader or an absolute file system path. A typical installation would place the keystore file in the conf directory of the profile where Teiid is deployed with a file name relative to the conf path.
keystorePassword - password for the keystore.
truststoreFilename - if "authenticationMode" is chosen as "2-way", then this property must be provided. This is the truststore that contains the public key for the client. Depending upon how you created the keystore and truststores, this may be same file as defined under "keystoreFilename" property.
truststorePassword - password for the truststore.
enabledCipherSuites - A comma separated list of cipher suites allowed for encryption between server and client. The values must be valid supported cipher suites otherwise SSL connections will fail.
SSL supports multiple authentication modes. In most secure intranet environments, anonymous is suitable to just bulk encrypt traffic without the need to setup SSL certificates.
anonymous - no certificates are exchanged, settings are not needed for the keystore and truststore properties.
Client must have org.teiid.ssl.allowAnon set to true (the default) to connect to an anonymous server.
1-way - the server will present a certificate, which is obtained from the keystore related properties. The client should have a truststore configured to accept the server certificate.
2-way - the server will present a certificate, which is obtained from the keystore related properties. The client should have a truststore configured to accept the server certificate. The client is also expected to present a certificate, which is obtained from its keystore. The client certificate should be accepted by the trust store configured by the truststore related properties.
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. User can restrict the cipher suites used for encryption by specifying the enabledCipherSuites property above in ssl configuration.