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.)
Related
I have a need to implement Open ID Connect in an ASP.NET Core 5 web app for authentication at an organization. I cannot test against the identity provider as this org has their own internal one.
I thought Open ID Connect (oidc) was a standard - yet when I look at docs and sample code for the various providers around, they all either have something provided with ASP.NET or I have to install their package.
For example, to use Google, the ASP.NET Core docs say to use services.AddAuthentication().AddGoogle(). For Facebook, it says to use .AddFacebook().
For Auth0, it wants me to install the package Auth0.AspNetCore.Authentication.
Is it not possible to just add OIDC authentication to my app and have it work with any OIDC provider and just change a configuration file to specify the authority URL, Client ID, Client Secret?
I'm confused about why I need these provider-specific calls and packages.
Architecturally, tieing an app to a single form of authentication is entirely wrong, as you suggest. These packages have limited use, perhaps for very simple use cases.
The original OAuth 2.0 spec from RFC6749, from 2012, describes how the OAuth framework is designed, to externalize difficult security from your apps:
The client only implements a code flow
It redirects to an authorization server (AS)
The AS can authenticate users in a myriad of potential ways, including many identity providers
After authentication (and possibly consent) the AS issues tokens to your apps
Tokens enable authorization in your APIs in a myriad of potential ways
Once you've implemented a code flow in your app, your set of users can potentially login in many ways, with zero code changes in the app:
Password sign in (a default option)
Multi-factor authentication (in a dynamic way potentially)
Cloud platform identity providers (for engineering staff)
CRM identity provider (for client focused staff)
SAML identity providet (for users from business partners)
Webauthn, Passkeys and Digital wallets (for some of your customers)
Unless you have a very good reason, stick to OpenID Connect standards based code flows in clients. You can do all of the above using the Microsoft libraries. Auth0 have good libraries also - just make sure you use the standards based ones.
OpenID Connect is an open standard that organisations use to
authenticate users. IdPs use this so that users can sign in to the IdP
From this blog.
And about the OIDC protocol, it allows you to authenticate users, and is designed for users to sign in many websites with only one account, usually it's a social/work account. This is only a protocol and you have to use an implement such as Google/Azure authentication to allow your users to sign in with their specific account.
By the way, since the implements are from different companies, so the configuration in our codes are different and they required different nuget packages like Microsoft.Identity.Web. For example, when using Azure, we need to set such as client id, client secret, tenant id, domain, redirect url... in appsettings.json.
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'd like to implement an OAuth2 server (technique doesn't really matter). I have a question about an approach:
Suppose I have an OAuth2 server which provides access_tokens and refresh_tokens. My users are going to login via an OAuth2 provider like Google and Facebook. When the external provider gives an OK sign to my application, I want to store the users name and email. After that, the user is known to my application and my server provides an access_token and a refresh_token. That gives my application actually two roles:
OAuth2 server (storing the users' information and provide access based on the aforementioned tokens).
OAuth2 client (getting authorization based on an external provider).
Does this comply with the RFC 6749 spec? Per my understanding, an OAuth2 server also have access the users' password and username, but I don't like to store sensitive information about the user. Or is this a common approach?
In a narrow sense, an OAuth server is a server for authorization. In a broad sense, people unconsciously expect the following three roles when they refer to an OAuth server.
Authentication
Authorization
Resource Management
Using an external provider (such as Google and Facebook) for login means that you delegate authentication to the external provider. Note that RFC 6749 says that authentication of resource owners (= end users) is beyond the scope (see 3.1. Authorization Endpoint).
Providing access based on access tokens is categorized as resource management. RFC 6750 should be referred to instead of RFC 6749. Resource management is also beyond the scope of RFC 6749.
However, behaving as an OAuth 2.0 client for the external server does not have any special meaning for client applications of YOUR server.
So, using an external provider does not necessarily mean that your server is an OAuth server. In other words, your server may behave as it likes without caring about RFC 6749 after the end-user authentication performed by an external server.
What makes people confused are some solutions that use external OAuth servers for "authentication" (not for "authorization"). Examples are OmniAuth and Auth0. Authentication is beyond the scope of RFC 6749, but the flow at the authorization endpoint includes end-user authentication as a step. Solutions such as OmniAuth use the authentication step for the different purpose. However, for the purpose of "authentication", OpenID Connect should be used.
If you don't like to store sensitive information about users, using an external OpenID Provider is an approach. Google, Facebook and other big names are now OpenID Connect server. Note that an OpenID Connect server is an OAuth 2.0 server at the same time, so you can use it as an OAuth 2.0 server. Stormpath is also worth checking. It offers "The User Management API".
If you want, it is also possible to delegate management of (a) access/refresh tokens, (b) meta data of client applications and (c) metadata of your services to an external pure "authorization" server. Authlete is an example. Authlete Defenitive Guide and the blog contain detailed generic information about OAuth 2.0 and OpenID Connect from an implementor's viewpoint.
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.
We are in a complex authentication environment and need to support authenticating against a number of disparate sources in applications we are developing. Since we don't want to be duplicating authentication code all over the place, we are looking at wrapping the various authentication sources with a single OpenID provider, and then having the applications all depend on that service.
The sources we have to allow authenticating against are things like Active Directory Username/Password, Kerberos, generic LDAP, external OpenID providers, etc.
For example, in the Kerberos case, when the user hits the OpenID provider's authentication page, if (s)he can be authenticated with Kerberos, and has already given permission to the requesting app, the user would be transparently authenticated as if a password was entered and passed back to the requesting app.
So, the question is, can we have create an OpenID provider that handles authenticating through all of these various methods? Does the provider have to implement how it authenticates the users in a specific way?
OpenID 2.0 specification do not specify how to authenticate users at the OpenID Provider there for it is vendor specific. So my answer is Yes, you can have an OpenID Provider that handles authentication through all those methods but you have to figure out how to, for example how to present the Kerberos tickets to the OpenID Provider is up to you to decide.