In this article we will discuss different types of user authentication mechanisms and how they should be used with Streams in a production or non-production environment.
Supported Authentication Mechanisms
Here are 3 types of user authentication mechanisms that were tested with Streams.¬† Note that any authentication backend that is compatible with PAM (Pluggable Authentication Module) is supported.
(1) LDAP (Lightweight Diretory Access Protocol)
In this mechanism LDAP is used directly.¬† The streams users are defined in an¬†LDAP server (only one set of users).¬† The streams users are not necessarily OS users.¬† All hosts that run AAS (Authentication and Authorization Service) must have a communications route to the LDAP server.¬† By using LDAP directly, Streams users can use the Streams Console, Streams Studio, Streams Excel plugin, etc. without having an account on the host system.
(2) PAM with LDAP backend
In this mechanism PAM is configured to use an LDAP backend.¬† This is very similar to #1 above, except that OS users and Streams user are all the same (configured in and authenticated by LDAP), which could lead to some security problems. ¬† For example, in a cloud environment, you may not want Streams users to be able to physically log into the hosts in your cluster (and be able to run OS commands).
(3) PAM with UNIX backend
In this mechanism Streams users and OS users are the same (but exist on the individual hosts).¬† If multiple hosts are used in the Streams domain, each host where AAS runs must have the same set of OS user accounts (Streams users) and their passwords must all be in sync.
Security¬†in Development Environment
PAM with UNIX backend is only recommended for use in a basic single host domain (test, development, or non-production environment).¬† This is the default mechanism used by Streams and it requires no configuration.¬† The domain property security.pamServiceName is used to control what PAM authentication service is used.¬† By default, Streams is configured to use the “login” PAM authentication service. ¬†i.e. security.pamServiceName=login.
Note that when using PAM with a UNIX backend, only the domain owner can log in to a Streams domain by using a user ID and password.¬† In a basic domain, you may only need one user (the owner of the domain) in which case this restriction doesn’t matter. ¬†However if you have a test domain that needs to be shared in a team environment, you may use the following options to work around this restriction:
1) Use the security.runAsRoot domain property to enable non-domain-owner clients to log in with a user ID and password, for example:
streamtool -d domain1 setdomainproperty security.runAsRoot=true
This property works for all InfoSphere Streams clients, including the Streams Console, Streams Studio, the streamtool command-line interface, and the REST and JMX domain management API clients.
Note: The security.runAsRoot property pertains only to resources where you have installed the domain host installation package and the domain controller service is registered as a system service.
2) The Streams Console can be configured to use certificate based client authentication as an alternative to the security.runAsRoot property.
3) Public and private keys can be used (genkey command) by the streamtool command-line interface as an alternative to the security.runAsRoot property.
Here is a link to the Knowledge Center article on how to setup a basic domain:
LDAP and PAM with LDAP backend are recommended for use in an enterprise domain (production environment) because:
- There is only one set of user accounts, so you don’t have to worry about keeping accounts on multiple systems in sync.
- The set of user accounts is on a separate server which can be made available to every host in the network.
- The domain will be HA (Highly Available) ready.¬† Note that we recommend redundant LDAP servers to achieve HA.
- Many companies are already using an LDAP server in their networks.
Here is a link to the Knowledge Center on how to setup an enterprise domain: