username@domainname
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.
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 security-domain attribute under the transport element in "teiid" subsystem in the <jboss-install>/standalone/configuration/standalone-teiid.xml file is used set the comma separated list of desired domains. For example, in default configuration under "teiid" subsystem you will find
<transport name="jdbc" protocol="teiid" socket-binding="teiid-jdbc">
<ssl mode="login"/>
<authentication security-domain="teiid-security"/>
</transport>
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 each transport type is can be different under Teiid. So, effectively one can configure different transports for JDBC or ODBC or multiple JDBC ports with different security domains
In existing installations an appropriate security domain may already be configured for use by administrative clients (typically for "admin-console"). If the admin connections (CLI and adminshell) are not secured, it is recommended that you secure that that interface by executing "add-user.sh" script in the "bin/scripts" directory.
JBossAS provides several LoginModules for common authentication needs, such as authenticating from a Text Based LoginModule or a 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 below XML fragment under "security" subsystem shows a Text based login module.
<subsystem xmlns="urn:jboss:domain:security:1.1">
<security-domains>
<security-domain name="teiid-security" cache-type="default">
<authentication>
<login-module code="UsersRoles" flag="required">
<module-option name="usersProperties" value="teiid-security-users.properties"/>
<module-option name="rolesProperties" value="teiid-security-roles.properties"/>
</login-module>
</authentication>
</security-domain>
</security-domains>
</subsystem>
The UsersRolesLoginModule is not recommended for production use and is strongly recommended that you replace this login module.
User names and passwords are stored in the <jboss-as>/modules/org/jboss/teiid/main/conf/teiid-security-users.properties file. These files must be available on classpath
# A users.properties file for use with the UsersRolesLoginModule # username=password fred=password george=password ...
JAAS role assignments are stored in the <jboss-as>/modules/org/jboss/teiid/main/conf/teiid-security-roles.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 instructions.
Configure LDAP authentication by editing standalone-teiid.xml under "security" sub system. Once the security-domain is defined, then edit the "security-domain" attribute for Teiid's "transport" for which you want use this LDAP login.
<subsystem xmlns="urn:jboss:domain:security:1.1">
<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>
<login-module code="org.jboss.security.auth.spi.RoleMappingLoginModule" flag="optional">
<module-option name="rolesProperties" value="${jboss-install}/standalone/configuration/roles.properties" />
<module-option name="replaceRole" value="false" />
</login-module>
</authentication>
</security-domain>
</security-domains>
</subsystem>
If using SSL to the LDAP server, ensure that the Corporate CA Certificate is added to the JRE trust store.
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 based on connection you are using
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>/standalone/configuration/standalone-teiid.xml under teiid subsystem on "transport" definition, add follows:
<transport name="jdbc" protocol="teiid" socket-binding="teiid-jdbc"/>
<authentication security-domain="teiid-security" krb5-domain="krb5-domain"/>
</transport>
Now we need to define a security domain context for kerberos with the name mentioned (kbr5-domain)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 -->
<subsystem xmlns="urn:jboss:domain:security:1.1">
<security-domains>
<security-domain name="krb5-domain" cache-type="default">
<authentication>
<login-module code="Kerberos" 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>
</security-domain>
<!-- teiid's default security domain, replace this with your own if needs to be any other JAAS domain -->
<security-domain name="teiid-security" cache-type="default">
<authentication>
<login-module code="UsersRoles" flag="required">
<module-option name="usersProperties" value="teiid-security-users.properties" />
<module-option name="rolesProperties" value="teiid-security-roles.properties" />
</login-module>
</authentication>
</security-domain>
</security-domains>
</subsystem>
Edit the "standalone.conf" file 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.
Consult the PostgreSQL ODBC client documentation.
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
<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">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>
</security-domain>
</security-domains>
</subsystem>
In the datasource 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 "UsersRoles" 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. 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.
<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">useFirstPass</module-option>
<module-option name="usersProperties">teiid-security-users.properties</module-option>
<module-option name="rolesProperties">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">teiid-credentialmap.properties</module-option>
<module-option name="managedConnectionFactoryName">jboss.jca:service=LocalTxCM,name=DefaultDS</module-option>
</login-module>
</authentication>
</security-domain>
</security-domains>
</subsystem>
In the datasource 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.