/subsystem=security/security-domain=teiid-security:remove()
/subsystem=elytron/security-domain=teiid-security:add(realms=[{realm=ApplicationRealm}])
/subsystem=undertow/application-security-domain=teiid-security:add(security-domain=teiid-security)
reloadSecurity Guide
The Teiid system provides a range of built-in and extensible security features to enable secure data access. This introduction provides a high-level guide to security concerns. The rest of the guide provides specifics on configuring clients, the Teiid server, and the application server.
Elytron Configuration
Examples in this guide are based upon the legacy security framework - which is still supported. If you want to migrate to the newer Elytron system you should remove the legacy teiid-security security domain and instead work with an analogous one created in Elytron. This also requires telling undertow to use the new security domain.
The standalone cli for this change to Elytron:
From there you would not completely follow the examples shown here, but rather use them as a guide to follow migration documentation such as Migrate Legacy Security.
Authentication
Client Authentication
JDBC/ODBC/Web Service 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 LoginModules for Teiid.
|
Caution
|
By default, access to Teiid is NOT secure. The default LoginModules are only backed by file based authentication, which has a well known user name and password. We DO NOT recommend leaving the default security profile as defined when you are exposing sensitive data. |
Teiid JDBC/ODBC also supports Kerberos authentication with additional configuration.
Auto-generated web services, such as OData, for consuming Teiid typically support HTTPBasic authentication, which in turn should utilize Pass-through Authentication.
Source Authentication
Source authentication is generally determined by the capabilities of JCA resource adapters used to connect to external resources. Consult the AS JCA documentation for the capabilities of source pooling and supplied resource adapters for more information. Typically a single username/password credential is supported, such as when creating JDBC Data Sources. In more advanced usage scenarios the source and/or translator may be configured or customized to use an execution payload, the Teiid subject, or even the calling application subject via Pass-through Authentication. See also Developing JEE Connectors and Translator Development
Pass-through Authentication
If your client application (web application or Web service) resides in the same WildFly 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 pass-through mode 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. This change can be made via the CLI or in the standalone-teiid.xml file if running in standalone mode. 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=true connection flag set. You may also set the security-domain on the VDB.
Authorization
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. Check out Reference Guide Data Roles chapter for more information. Any source level authorization decisions are up to the source systems being integrated.
VDBs without data roles defined are accessible by any authenticated user. If you want to ensure some attempt has been made at securing access, then set the data-roles-required configuration element to true via the CLI or in the standalone.xml on the teiid subsystem.
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 AS instance must be configured for SSL as well so that Any web services consuming Teiid may use SSL.
Configuration
Passwords in configuration files 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.
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.