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.
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.
We are just getting started with implementing ADFS authentication, however are still getting our bearings in terms of how to integrate it with other applications and systems.
From what I can tell, the main supported authentication systems for many of the applications we use (I am specifically interested in Blackboard authentication at the moment) are ones like Shibboleth, OAuth, CAS, LDAP and each application's own authentication implication.
What I'm not sure, however, is if (and where) ADFS falls under these categories. Conceptually, it seems like a type of "Central Authentication System" (CAS), but is more similar to Shibboleth (also a federated identity management system). Do some of the main categories of authentication overlap each other? From the documentation, I can see:
AD FS provides Web SSO to federated partners outside your organization, which enables their users to have a SSO experience when they access your organization’s Web-based applications.
The Central Authentication Service (CAS) is a single sign-on protocol for the web. Its purpose is to permit a user to access multiple applications while providing their credentials (such as userid and password) only once. It also allows web applications to authenticate users without gaining access to a user's security credentials, such as a password. The name CAS also refers to a software package that implements this protocol
Shibboleth is among the world's most widely deployed federated identity solutions, connecting users to applications both within and between organizations.
My main question is this:
Is ADFS a type of one of those main implementations (like CAS)...
or is it a proprietary version of something like Shibboleth, but can be used interchangeably...
or does it fall in a category outside of one of of one of those systems (and hence need to be handled through a manual or custom process)?
Just to clarify:
Shibboleth is an Identity Provider (IDP) aka Security Token System (STS)
OAuth is an authentication protocol
LDAP is an Identity repository
An IDP authenticates against a repository using an authentication protocol.
ADFS is also an Identity Provider (IDP) aka Security Token System (STS)
I've not seen the term "CAS" used in this context.
Shibboleth and ADFS perform the same function and are (in a general sense) interchangeable.
In practice, they aren't because Shibboleth only supports the SAML 2.0 protocol whereas ADFS supports WS-Fed, SAML 2.0 and OpenID Connect / OAuth 2.0.
Some additions/updates to the accepted answer from rbrayb a few years later:
Shibboleth IdP is the reference implementation for SAML and also supports CAS and OpenID Connect.
Shibboleth SP is the SAML service provider from the same project.
CAS (Central Authentication Service) is another web-SSO protocol like SAML; it's also the name of the reference implementation, which also supports SAML, OIDC, etc.
OAuth is an authorization standard.
SAML, CAS, OpenID, Kerberos and other SSO protocols are based on the concept of a Trusted third party.
LDAP happens to be a service in which, in a given organization, most or everyone already has an account with a password. There is nothing inherently special about it as a server to authenticate against. It could just as well have been a telnet server or web server with basic auth or a SQL server; in any of these cases, the application has to collect the username & password and pass those through to the back-end authentication service, unlike SSO protocols. (LDAP happens to provide a vendor-neutral, non-interactively-focused interface for the authentication, which is part of the reason it's often put to this task rather than the others.)
(I originally tried adding this as a comment but comments do not support the formatting I wanted.)
We have requirement of build .NET based plugin/component for enabling Authentication against multiple IDP providers like ADFS, Azure AD and Shibboleth based on DB configuration. i.e, depending on the configurable parameter the anonymous user will be authenticated against any one of the IDPs like ADFS, Azure AD or Shibboleth IDP.
Our application URL ("https://www.contoso.com/ProcessToken.aspx") will be registered as RP Identifier in all of the 3 providers.
We won't make any web.config changes for any of the providers.
At run time, User will access common page(Proesstoken.aspx) who needs to get redirected to the any of the Login page URLs at the provider (ADFS, Shibboleth, Azure) for Authentication based on User Organization. (For ex: User A to ADFS, User B to Shibboleth etc)
After Successful authentication at the IDPs the user needs to get redirected by the provider (ADFS/ Shibboleth/ Azure AD) to the RP Url registered.
In the redirected page (ProcessToken.aspx), we are planning to get the security token and decipher the claims required.
The main intention is to decouple authentication away from application logic and it should be extendable to other providers in future.
PS: Considered options like OWIN Authentication Middle Tier, .NET Component etc.
Need guidance on How and where to start.
Have a look at IdentityServer 3 which implements this multi-auth scenario or OWIN : ASP.NET MVC application with multiple authentication options.
The main point is that you use NuGet to download all the protocols you require and than use OWIN to pull them all in via app.use.
You can configure ADFS to have Claims Provider Trust with the other IDP's Owin will acknowledge the authentication. The difficult part will be reading the attributes from the tokens. ADFS under the covers in conjunction with the Owin framework use ws-federation, I have not figured out how to read the SAML.
What gets confusing is that at one time the answer was WIF but now that 4.51 has been released, WIF was moved into Owin. The documentation for a multi-tenant application is sketchy at best.
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.
We have a SaaS system based on SAML 2.0 authentication using an Identity Provider and we want to provide several ways of logging in, Form Authentication, Facebook, etc. Is it possible to connect the SAML system to a remote application using Active-Directory, ideally to gain access to the API also but most importantly to be able to use their authentication with the remote active directory as a means of logging in to the SaaS system?
Check out PingFederate and PingOne from Ping Identity (note: I work for Ping). We have complete IDP and SP support (SAML1.1, 2.0, WS-Fed (Passive)) as well as support for LDAP, SFDC, OpenID and other Cloud Identity providers (LinkedIn, Facebook, etc). We also have support for Web Services security via Oauth2 and WS-Trust.