We are in the slow process of implementing a 7.x environment that include IS, Broker and MWS. The documentation recommendation suggests that the Central User Directory is a requirement for MWS and that when configured, the Integration Server must use it also.
It looks like the authentication process would go: client → IS → MWS → CUD/LDAP
which seems excessive and having a portal as the authentication provider, dangerous for your production integrations.
If the IS instances are to be used as external web service providers not only to the MWS CAF service calls, the user authentication is potentially going to be bottle-necked through the MWS server. Does anyone know and implemented, LDAP authentication as well as Central User Directory in the Integration Server?
The following is a consolidation of input from a number of folks, so shared credit all round, but this may help clarify the position for you.
The Central Users capability in IS replicates the behaviour in MWS for accessing user information, but does not (with one exception) rely on communicating through the MWS itself. Although MWS provides the user interface for configuring and managing the user details, it is not normally involved in the run-time activity, so:
The Central Users function causes IS to use the database directly and not through MWS - this does mean the IS must be able to access the MWS database though
If MWS is using LDAP to get user information, then although the IS uses the Central Users database connection to get the LDAP server information, it then goes direct to the LDAP server to retrieve actual user information
The IS can obtain user credentials and roles/role attributes through the Central Users mechanism, (but would still need to use the database for the actual details if MWS system directory is used, or LDAP server config if MWS is using LDAP), or IS can get the same from the LDAP server directly (no need to refer to the MWS database)
If the MWS UI is using hybrid authentication (either in an application portlet using web services on IS, or in the TN Console UI in MWS) then the IS does call back to the MWS to validate the SAML tokens since in this case MWS is the authority for the tokens. This is separate from IS user authentication and so does not involve Central Users, although MWS could have issued the token where IS and MWS share user information through Central Users anyway.
The one main exception to all this is that if the Monitor in MWS is being used, then IS also does call back to the MWS to check configured roles - Monitor does not use the Central Users feature directly (in the current versions)
It is worth noting that the cases where MWS is supporting the authentication modes (last two) where IS does call back are not totally relevant to your case, because the interaction is initiated within MWS. (So if MWS wasn’t available that interaction pattern wouldn’t arise.)
There are ongoing changes to the overall security model within the product suite, so this will consolidate over time, but generally, we recommend Central Users for most environments now. If the MWS database cannot be reached, then Central Users can’t be used, in which case a direct connection to the same LDAP environment may be appropriate.
It is not currently possible to configure a single IS to use simultaneously an LDAP server and Central Users (although if MWS uses LDAP, then Central Users would result in an LDAP server being queried by the IS).