We have an application running on Tomcat currently and using LDAP as the means to authenticate users to our enterprise AD.
It is required to migrate this application to cloud (on AWS EC2) and to integrate with ADFS over SAML for login with MFA enabled.
Wondering if there are any guides on the the steps to be followed to make this happen ? What are the configurations that I need to enable in ADFS for my application and what configuration changes are needed on tomcat server.xml to have the connector integrate with ADFS rather than LDAP. Thanks.
Regards,
Raunak
Not a Tomcat guru but from the point of view of ADFS and SAML:
You need to use a client-side SAML stack in your application. This provides the SAML plumbing.
You then need to add a SAML RP to ADFS.
For MFA, typically you use Azure AD to provide the MFA.
(There used to be an on-premises ADFS MFA Server - that is now deprecated).
If that is not an option, there are third-party providers.
I'm building a SaaS and my idea is to allow my customers to use their own authentication system to login to my app.
what's the best approach to do this? I will have multiple customers and each of them can configure SAML SSO.
I'm also concerned about how to initially load the users.
Usually companies provide a list of users emails and I just bulk insert them into the database or the account will not have any users until they start to sign in?
How to manage the scneario when a user is not part of a company anymore? companies provide a list of users to deactivate?
this is more like a conceptual question because these days if you want to build enterprise software you must integrate with they authentication systems.
Question 1:
I'm building a SaaS and my idea is to allow my customers to use their own authentication system to login to my app.
what's the best approach to do this? I will have multiple customers and each of them can configure SAML SSO.
Answer:
(1) A unique subdomain is assigned to each customer, for example,
customer1.your-software.com
customer2.your-software.com
customer3.your-software.com
(2) The subdomain of each customer corresponds to a SAML SP with corresponding SAML SP metadata. The entityID and AssertionConsumerService endpoint of SAML SP for each customer should be different.
For exmple, assume that Shibboleth SAML SP is used, entityID of each customer can be
https://customer1.your-software.com/Shibboleth.sso/Metadata
https://customer2.your-software.com/Shibboleth.sso/Metadata
https://customer3.your-software.com/Shibboleth.sso/Metadata
AssertionConsumerService endpoint of each customer can be
https://customer1.your-software.com/Shibboleth.sso/SAML2/POST
https://customer2.your-software.com/Shibboleth.sso/SAML2/POST
https://customer3.your-software.com/Shibboleth.sso/SAML2/POST
(3) Each customer can upload their unique SAML SP metadata to their their own authentication system (i.e., SAML IdP (Identity Provider)).
Cloud-based SAML SP enterprise application Salesforce has implemented the similar solution described above.
Similarly we have implemented a parallel solution for our cloud-based SAML IdP which is part of of Zero-Password Authentication and Authorization System.
Question 2:
I'm also concerned about how to initially load the users. Usually companies provide a list of users emails and I just bulk insert them into the database or the account will not have any users until they start to sign in?
Answer:
Because SAML SP and SAML IdP (i.e., your customer's own authentication system) have established the mutual trust through metadata exchange, SAML SP (equipped with your enterprise software) should trust all the user info federated from SAML IdP (i.e., your customer's own authentication system).
(1) The account will not have any users until they start to sign in.
(2) When a new user initially signs in to your cloud-based enterprise application, after failing to find the user info from the database, your enterprise web application will insert the new user info into the database.
Question 3:
How to manage the scneario when a user is not part of a company anymore? companies provide a list of users to deactivate?
Answer:
(1) When a user is not part of a company anymore, your customer will deactivate the user from their authentication system. Then the user is NOT able to log in to your cloud-based enterprise web application
(I) When a user accesses your cloud-based enterprise web application, the user is redirected to your customer's own authentication system (i.e., SAML IdP).
(II) The deactivated user will NOT be authenticated by your customer's own authentication system.
(III) The deactivated user will NOT be redirected back to your cloud-based enterprise web application with SAML assertion/response which carries the user info. Thus, the deactivated user will fail to log in to your cloud-based enterprise web application.
(2) Your enterprise web application assigns administrative privilege to the IT head of each customer for their own organization subdomain such as customer1.your-software.com.
After logged in to your enterprise web application, the IT head can remove/delete/deactivate any user of their organization such as customer1 from the database of your your enterprise web application.
The official Okta website What is SCIM? provides the following description on SCIM (System for Cross-domain Identity Management).
When changes to identities are made in the IdP, including create, update, and delete, they are automatically synced to the SP according to the SCIM protocol.
Follow-up Question #1:
when the user authenticated with SAML and is redirected to the callback url (my app) what´s would be the ideal flow there?
Answer:
(1) After a user authenticated with SAML IdP, the user is redirected to the AssertionConsumerService URL of your enterprise application which is bound to subdomain of each customer of your enterprise application.
(2) 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 and a SAML SP web application (which can be regarded as a simplified enterprise application to allow paid users to access protected web resources).
Shibboleth SAML IdP is responsible for identity federation.
OpenLDAP is responsible for identity authentication.
You can use the above GitHub repository to simulate your SAML SP enterprise application with multiple customers and their corresponding SAML IdPs.
(I) Run three (3) SAML SP demo application docker containers (which correspond to three (3) SAML SP enterprise applications subscribed by three (3) customers) on the same physical machine/server (such as Ubuntu server).
(I.A) Each SAML SP demo application runs on different "external" ports of Docker container.
docker run -it --rm -p 2081:80 -p 2441:443 --name="shibboleth-sp-1" example/shibboleth-sp:latest
docker run -it --rm -p 2082:80 -p 2442:443 --name="shibboleth-sp-1" example/shibboleth-sp:latest
docker run -it --rm -p 2083:80 -p 2443:443 --name="shibboleth-sp-1" example/shibboleth-sp:latest
(I.B) Use HAProxy to map different "external" ports of Docker container to different subdomain of your customers, such as
2441 to https://customer1.your-software.com/
2442 to https://customer2.your-software.com/
2443 to https://customer3.your-software.com/
(II) Run three (3) SAML IdP docker containers (which provide SAML authentication for three (3) enterprise applications subscribed by three (3) customers) on another same physical machine/server (such as Ubuntu server).
For demo purpose, you can use two (2) physical machines for SAML IdP and SAML SP with local DNS and port configuration for different domain name, for example,
10.10.40.10 customer1.your-software.com customer2.your-software.com customer3.your-software.com
10.10.40.11 customer1.saml-idp.com customer2.saml-idp.com customer3.saml-idp.com
(II.A) Each SAML IdP runs on different "external" ports of Docker container.
docker run --rm -it ... -v $(pwd)/ext-conf:/opt/shibboleth-idp-ext-conf --link openldap:openldap -p 8441:8443 --name="shibboleth-idp-1" example/shibboleth-idp:latest $#
docker run --rm -it ... -p 8442:8443 --name="shibboleth-idp-2" example/shibboleth-idp:latest $#
docker run --rm -it ... -p 8443:8443 --name="shibboleth-idp-3" example/shibboleth-idp:latest $#
... means the missing docker parameters to be added (with reference to run.sh)
(II.B) Use HAProxy to map different "external" ports of Docker container to different subdomain of SAML IdP corresponding to your customers' SAML SP application such as
8441 to https://customer1.saml-idp.com/
8442 to https://customer2.saml-idp.com/
8443 to https://customer3.saml-idp.com/
(III) Exchange the SAML metadata between SAML SP (e.g., https://customer1.your-software.com/) and SAML IdP (e.g., https://customer1.saml-idp.com/).
Remarks
You can check the Salesforce SSO and Box SSO website to learn how Salesforce and Box assign different sub-domains to their different customers, thus allowing customers to configure their subdomains as different SAML SPs for customers' own SAML IdPs.
Note that our Zero-Password Authentication and Authorization System is technology partner of Box.
Follow-up Question #2:
should I create a jwt on my app with that information and if that jwt expires I should redirect again to SAML?
Answer:
No. You do NOT need to create a jwt on your enterprise application.
Instead, when SSO session expires, your enterprise application should be redirected to SAML IdP for another authentication.
Follow-up Question #3:
is there a "free" idp I can use to test the implementation are you aware of any?
Answer:
Shibboleth SAML IdP is a "free" idp I can use to test the implementation.
There are two (2) options for leveraging Shibboleth SAML IdP to test the implementation of your SAML SP enterprise application.
(1) Running Standalone Shibboleth SAML IdP
How to build and run Shibboleth SAML IdP and SP using Docker container at GitHub repository allows you to build and run a standalone IdP Simulator at your own testbed. Running a standalone SAML IdP Simulator by yourself allows you to test your SP code and debug your SAML SP log by checking server logs of both IdP and your SP developed by you.
(2) Utilizing the online Shibboleth SAML IdP
TestShib is the online Shibboleth IdP simulator built and run by the Shibboleth community.
The website of TestShib demonstrates
"One of the original creators of the TestShib service has built an alternative to TestShib for everyone's benefit. The site is called SAMLTest (offered by Signet)* and you can learn more about them by browsing over to those locations."
Scim is the protocol used to provision users from an identity provider to your database.
Scimgateway is one implementation https://github.com/jelhub/scimgateway
I have experience setting up SSO across dozens of apps for an organization with 15-20k users. Here are some tips from experience that may be relevant:
If you have no real need to create accounts, don't. Instead, rely on valid IDP responses as proof that they have been authenticated. If you need authorization, maybe you can rely on the IDP to manage that. AWS, for example, looks for a multi-valued attribute https://aws.amazon.com/SAML/Attributes/Role to determine what role(s) the IDP asserts the user has. If there are no roles, the user is authenticated but can't do anything.
The premise of SSO is that the IDP will no longer authenticate users when they leave, so perhaps you do not need to de-provision users when they leave. If you need to remove stale data in your SaaS (ex. you want to show all organization users but don't want to include those who left), perhaps instead just filter out users who haven't logged into SaaS in some period of time.
If you really do need a method to de-provision accounts (for example, because you allow user-linked API keys which circumvent SSO), you can initially empower organization admins do that manually. I believe Slack uses that model, even for SSO-managed users.
If you want to allow SP-initiated logins (AWS doesn't allow this but gmail does), use a google-like process where a user first inputs only their email address (or an empty password like New Relic). The email will allow you to lookup the organization's IDP details and redirect the user to the organization's own IDP.
The SAML spec is nearly 15 years old, so in addition to SAML, consider supporting OAuth/OIDC. This will allow organizations to rely on GitHub, LinkedIn, etc, for example, as their IDP instead of setting up their own (if you decide you don't need IDP-managed roles).
From go-live, provide support for a few popular IDPs like AD FS, Auth0, Google Apps, etc. to minimize the friction to get your SaaS adopted for corporate use.
You will need to have a SAML IDP as part of your SaaS.
Then you give other parties your metadata and they give you theirs so you can integrate.
You may wish to use Identity aaS e.g. Azure AD, Auth0 etc.
In terms of users, you are allowing other IDP to authenticate. These other IDP control the onboarding of their users. You don't have to worry. They use federation and federation implies that they use their credentials to access your system.
If you want "standalone" users, you need a registration page, a password reset page etc. This is not part of SAML.
These facilities are provided by the cloud IDP as above. Their logon pages typically provide sign up, sign in and password reset.
Planning to use ADFS to federate. One big challenge that we find is that not all applications are claims aware, also every application has a different role based access. In such a how can we achieve 100% SSO Authentication and Authorization using Identity Claims.
In case ADFS cannot support such a requirement, What other vendor solutions are available which can supports such a requirement.
A claims-aware application in the .NET world uses WIF / WS-Federation to get a set of claims in a SAML token which are then used to control user access and functionality.
ADFS only answers to WS-Federation or SAML requests.
So to get a non claims-aware application to use AFDS, the application needs to be changed to add support for either of these protocols.
Refer: SAML : SAML connectivity / toolkit and the links inside the post.
Or you could go the other way and put something like an OpenAM agent around the applications and then federate OpenAM and ADFS.
ADFS on Server 2012 R2 has a new feature as part of the Web Application proxy, refer Create a Non-Claims-Aware Relying Party Trust.
There's a walkthrough here - Walkthrough Guide: Connect to Applications and Services from Anywhere with Web Application Proxy
and a good example here - First Impressions – AD FS and Window Server 2012 R2 – Part II.
We are looking at IDaaS offerings (OneLogin, Okta, etc.) When we've asked if they support CloudBees they said they do not, but they said if you support SAML authentication that they can add support for CB very easily. Do you know if you support SAML?
There is no specific support for SAML - however applications that are hosted on the platform would well support it.
CloudBees supports SAML integration with any SAML IdP endpoint. The SAML IdP endpoint could be running on your premises or you can use IdP providers such as OneLogin, Okta, Centrify etc. they also provide CloudBees app that you can configure for SAML. Both flow - SP initiated or IdP initiated flows are supported as well.
See, http://developer-blog.cloudbees.com/2013/09/cloudbees-now-offers-saml-20.html
Centrify definitely has a pre-built SAML app for CloudBees.
You can sign up for free here to test it.
https://www.centrify.com/free-trial/
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.