I am trying to migrate our companies Active Directory using LDAP to whitesource, however it does not officially support LDAP. I am trying to see if there is a way to install SAML on my LDAP which could enable whitesource to connect to my LDAP using SAML. Any help would be greatly appreciated!!
You can not really use SAML to migrate user identity information from AD to some other identity silo.
However you could use ADFS (on top of AD) to act as an SAML IdP, WhiteSource as SAML SP and then perform SAML 'autofederation' to populate the identity silo on the SP side with some specific identity attributes.
I don't know whitesource though. (https://whitesource.atlassian.net/wiki/spaces/WD/pages/547356829/WhiteSource+SAML+2.0+Integration ?)
Related
For a 1 day project (call it a hackathon) we will be looking into replacing a custom built authentication and authorization system with one that we can buy.
After all, there are people who are better at this stuff than we are.
Non-cloud, hard requirement is on-premise installation possible
Can authenticate against Active Directory using LDAP
Can authenticate using SAML against ADFS
Management of users, roles etc without a directory is an option (most likely option to actually use during the hackathon)
Use open standards, SAML, OpenID, OAuth2
There are so many SAML-based products, but many are cloud-only, which unfortunately for us is not an option (reason: our products run on closed enterprise networks), so services like Okta are unfortunately not an option :(
The following list is quite complete, but doesn't give me any indication on how hard it is to install + get up and running in a few hours:
https://en.wikipedia.org/wiki/SAML-based_products_and_services
Any suggestions for products to try?
My eye caught these ones:
miniOrange, Ping Identity, 10duke
[addition]
I am using a Java stack for web apps.
How to build and run Shibboleth SAML IdP and SP using Docker container at GitHub repository provides the instruction on building a SAML-based Authentication/Authorization Provider using Shibboleth SAML IdP and OpenLDAP.
Shibboleth SAML IdP is responsible for identity federation.
OpenLDAP is responsible for identity authentication.
I have validated SAML Single Sign-On (SSO) provided by Docker-running Shibboleth SAML IdP (Identity Provider) and OpenLDAP for the following enterprise applications. In other words, I leveraged Docker-running Shibboleth SAML IdP and OpenLDAP to log in to the following enterprise applications successfully.
Microsoft Office 365
Google G Suite
Salesforce
Dropbox
Box
Amazon AWS
OpenStack
Citrix NetScaler
VMware vCloud Director
Oracle NetSuite
Another StackOverflow question Setting up a new Shibboleth IdP to work with an existing SAML SP discusses the SAML configuration between IdP and SP.
OpenLDAP is not OpenID Connect or OAuth 2.0
Have a look at identityserver4.
It's OpenID Connect / OAuth2 by design and it does have a plug-in SAML stack.
Or if you have a Windows server, use ADFS.
FOSS - Shibboleth or KeyCloak
The definition of 'closed' (network) might be interesting to examine. No access to outside at all, not on any port, noway/nohow? In that case, yes, you want an on-prem service. If there's gated access to outside, it's likely that many hosted identity services could work.
I work for a healthcare SaaS company where all of our SSOs use SAML 2.0, and we cannot use LDAP. We have one particular client right now who wants to use ADFS to SSO from their intranet to our site and seem to act as though LDAP is the only option (and that they can't produce SAML assertions for our handshake).
What is the difference between SSO and SAML? What can one accomplish that the other one cannot? Why would my company require SAML over LDAP?
What I'm theorizing from research but am welcoming correction on:
-SAML is safer than LDAP because of authentication/encryption (but I don't know the specifics)
-LDAP is more widely used with companies but SAML is often used with enterprise clients
-LDAP can also be used to control users' access to other programs/sites they have access to (i.e. IT and revoking access to a terminated employee)
Thank you for your help!
Using LDAP for authentication requires disclosing the user's credentials at the application. If the application is running in a different administrative domain (i.e. a SaaS app) this is less preferred since the user's credentials end up in a 3rd-party domain.
OTOH SAML allows you to sign in to the application without disclosing the user's credentials to the application itself which offers increased security. It also increases convenience since the user only has to remember one credential.
LDAP is an Identity repository.
SAML is an Identity standard that could use LDAP as the repository. Or it could use something else like AD.
Just a correction - SAML does not use SOAP.
You can configure ADFS 4.0 (Server 2016) to authenticate against an LDAP and ADFS supports SAML.
If ADFS was configured that way, you would use SAML for SSO, authenticate against a LDAP and get a SAML token returned.
I work for a company that offers a SaaS solution. We currently allow customers to SSO in using ADFS on their side and we are the Service Provider accepting a SAML assertion. We seem to get a large number of people requesting SSO via LDAP though. I understand that LDAP is the protocol to authenticate users on an AD network. I'm wondering - is this synonymous with ADFS or are they talking about something else?
If ADFS isn't necessarily the best practice for LDAP authentication over the internet, could someone give me a high level explanation on how we would authenticate against another website using LDAP?
AD is an "extension" of LDAP in that it does more but still handles the normal LDAP query strings etc.
When people talk about LDAP they are normally referring to ADAM / OpenLDAP / OpenDS etc.
ADFS v3.0 only works against AD. The next version (ADFS vNext) will work against LDAP.
The easiest way is to federate ADFS with something that does support LDAP e.g. Shibboleth or simpleSAMLphp.
Our application uses federated single sign-on authentication process and we already have our identity provider set, up and running. I have the application instance running too, that I would like to integrate to MS CRM using our IdP for authentication.
Do you know if I could get, somewhere, steps on what I should do to set MS CRM to use our IdP (upload our idp.xml ...), I didn't manage to find anything on the CRM official sites?
Our IdP is ForgeRock OpenAM and SAML should be used for communication.
Is it possible at all to use other IdPs but ADFS with MS CRM?
Thank you for the time spent on replying!
I don't know if the CRM STS supports SAML directly - if it's similar to the SharePoint STS, it doesn't.
The easiest way is to configure CRM with ADFS in the normal way and then federate ADFS with OpenAM. ADFS has full SAML support.
Note that you need to use OpenAM's federation functionality.
How to import users from ADFS server to openam. I refered this doc
https://wikis.forgerock.org/confluence/display/openam/OpenAM+and+ADFS2+configuration
where they are saying users which are present on ADFS server must be present on openam.But if
I have thousand of users created on ADFS then can't create them manually on openam.so is
there any way to import the users from adfs server to openam either by accessing openam url
i.e through openam GUI or from java app.
Thanks,
OK - that document is confusing.
The difference between the IP and the SP is that only the IP has a credential store (AD in this case).
So the users only have to exist in AD.
If you look at the diagram, there is no credential store in Network A.
That's the whole point of federation.
Update:
Apologies - I seem to have confused some people.
That article refers to Account Linking but as per Using AD FS 2.0 for interoperable SAML 2.0-based federated Web Single Sign-On:
"AD FS 2.0 does not support the account linking scenario. Such a scenario can still be achieved in some ways with an appropriate incoming policy."
For federation, there's a good article here:
ForgeRock OpenAM 9.5.3 and AD FS 2.0 Integration : Part 1
but note that this looks at using OpenAM as a SAML 2.0 Identity Provider (IdP) and AD FS 2.0 as a SAML 2.0 Service Provider (SP).
There are three parts to this article - all in the blog.
Actually OpenAM does not store user accounts, they are stored in a so called Identity Repository (currently mostly used is an LDAP Directory Server, RDBMS has some issues yet).
You could retrieve the data from AD and import it in the Identity Repository.
However if you own ADFS and OpenAM why don't you let OpenAM consume the identities from AD by configuring it as an Identity Repository? You may search on the openam user alias ... plenty of explanations there.
About SP and IdP ... users are only AUTHENTICATED at the IdP but the user may exist under a different account on the SP side. Part of Federation/SAML is 'account linking' (not only single sign on) so identities (user accounts) can exist on SP and IdP side