JBoss.orgCommunity Documentation
The Teiid system provides a range of built-in and extensible security features to enable the secure access of data.
For more detailed information see the:
Console Guide – for instructions on how to set a range of security settings, on installing Membership Domains, and on setting up roles.
Connector Developers Guide – for information on how custom connectors can be developed with advanced security features.
Web Services Guide – for information on how to secure web service access to Teiid
Client Developers Guide – for information on how to authenticate through JDBC and ODBC.
JDBC, ODBC, and web service clients may use simple passwords, a pass-through mechanism called a trusted payload, or a combination of that and related information 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 from the trusted payload or another mechanism. In any case it is up to the installed membership domains to actually determine whether a user can be authenticated.
NOTE: All passwords or security credentials that are passed through the Teiid system will either be encrypted or sent of an encrypted transport by default.
Authorization is split into three areas of concern. Admin roles, repository roles, and data roles can be managed in the Console to enforce authorization of administrative tasks, the MetaBase repository, and enterprise data respectively. A role is simply a collection of permissions and a collection of entitled principals. Currently the Teiid security system only allows principals that represent groups to be assigned to a role. The set of available groups are determined by the installed membership domains.
Membership domains are at the core of Teiid’s security system and bridge the gap between Teiid and an external security system. A membership domain provides:
User authentication
A set of groups
The groups to which an authenticated user belongs
Access to membership domains is coordinated through the Membership Service. The Membership Service together with the Authorization Service implement the necessary logic to authenticate users, determine role membership, and to enforce roles.
There are multiple types of membership domains that allow for connectivity to different security systems. A Teiid server environment can be configured with multiple membership domains (there can be multiple instances of a given membership domain type). Each membership domain instance must be assigned a unique domain name in the Teiid system. The domain name 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 membership domains will be consulted in order until a domain successfully or unsuccessfully authenticates the user. If a membership domain reports the user does not exist or that the credentials are not recognized, that is not considered an unsuccessful authentication and the next membership domain will be consulted.
If no membership domain can authenticate the user, the logon attempt will fail. For any failed logon attempt the message the users sees will always be the same. It will simply indicate the user could not be authenticated by any membership domain – it will not reveal any further details which could potentially be sensitive information. Details including invalid users, which domains were consulted, etc. will be in the server log with appropriate levels of severity.
The Teiid System provides LDAP and File membership domain types.
The LDAP membership domain provides flexible integration with a variety of LDAP servers through JNDI (Java Naming and Directory Interface). Enterprise environments with an LDAP compliant directory server should attempt to utilize the built-in LDAP membership domain before attempting to create a custom solution.
The File membership domain utilizes a simple set of text files to authenticate users and to define their groups. Please note however that the File membership domain is not intended for production use.
Instructions for configuring both of these can be found in the Teiid Console Guide.
Support will be added for additional membership domains with subsequent releases.
In circumstances not covered by a built-in membership domain, a custom membership domain allows the Teiid security system to interact seamlessly with other enterprise security providers.
Java development is required to implement a custom membership domain. The API and a full example are covered in the following chapters of this document.