Regarding SSO Authentication Using SAML Integration

I would like to ask a few additional questions. First, is it possible to set up an LDAP server on the same machine (server) where DOORS Next is installed? For context, both Jazz and JAS are installed on the target server.

Additionally, I would like to clarify the meaning of the following statement. Does this mean that SAML authentication alone is sufficient if the purpose is only to access DOORS Next via a web browser, and that LDAP is additionally required when extending authentication to tools such as Cameo DataHub or API tools?

"This step provides a mechaism for non-web clients to authenticate."

There are several important considerations here:

 - for basic web based access, SSO via SAML works well

 - if you have rich client applications, such as ELO Publisher, Excel, and the EWM Eclipse and VSCode clients, you need a password. This can be done by enabling Application Passwords on the JAS. Users can then create passwords to use with specific clients, mapped to their username and login

The really big thing that is brought up above is that you also need an LDAP connection, and you really need that connection mapped to the directory you're using for the SAML. There are two reasons for this:

 - the main one is for mapping users to Jazz groups, as mentioned above. This is actually something that could be transmitted as part of the SAML information, but it's not done for ELM, and it can be a bit fiddly to implement

 - the other key reason you need an LDAP connection is if you use digital signatures in any of the applications. A digital signature requires explicit user password authentication at the time, and so only an LDAP connection will work here

I have several clients who are using ELM SaaS on IBM Cloud, and who turned on SSO using Azure Entra as the IdP and SAML provider. Entra seems to be by far the most popular directory out there at the moment, but it doesn't provide LDAP capability and you have to jump through a million hoops to add it in, which is really annoying.

Despite this, they still proceeded with the SSO enablement and IBM suggested a workaround of leaving the default IBM supplied LDAP directory connected to their SaaS instance. While this seemed like a possible workaround, in reality it caused a lot of problems:

 - JazzAdmins had to add the user into BOTH the Entra directory system as well as the IBM supplied LDAP, making sure the user ID and email were identical. This was the only way to add Jazz groups

 - JazzAdmins had to then administer users in two places

 - the worst thing was that two of my clients made heavy use of digital signatures. These checked the user's credentials against the IBM supplied LDAP, which meant that the users had to maintain TWO passwords for the same system. Even worse, out of 500 users, maybe 60 of them signed things. IBM turned off the automatic password expiry emails because it was confusing the regular users. But then the signing users (who were the most senior management) had their LDAP passwords silently expire and would then get all sorts of weird errors when trying to sign things in ELM

 - the final straw was that these senior users would go into Entra and change their password, but this wasn't the one used for signing. They would then go into the IBM supplied LDAP and reset it using the SAME password as their Entra ID.

So the reality was that, unless you have a SAML IdP that also provides LDAP, you end up with a WORSE security problem than having a stand alone ELM system and separate logins.