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 client application uses a security-domain to handle the security concerns, then you can configure Teiid to use the same security-domain and not force the user to re-authenticate for using Teiid. In this case Teiid looks for a authenticated subject in the calling thread context and uses for its session and authorization purposes. To configure Teiid for this pass-through authentication mechanism, you need change the Teiid's security-domain name to 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 Teiid connection using Local Connection, with PassthroughAuthentication=true 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 domains) names can be used to fully qualify user names to authenticate only against that domain. The format for a qualified name is username@domainname.
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.
JBossAS provides several LoginModules for common authentication needs, such as authenticating from text files or LDAP.
The UsersRolesLoginModule, which 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. Note that this is typically not for production use and is strongly recommended that you replace this login module. Please also note that, 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 both or single login module.
See LDAP LoginModule configuration for utilizing LDAP based authentication. If you want write your own Custom Login module, check out the Developer's Guide for instructions.
In some use cases, user might need to pass-in different credentials to their data sources based on the logged in user 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 setup 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. This 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, simply 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 like 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 level 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 credentail to that role. So, it is container of credentials that map 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 setup 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 it's 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.1. 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>
</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. This must be available in the classpath of Teiid Server.
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.
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.