I've been tasked with determining the feasibility of building an application that would act as a proxy between platforms that offer single sign-on capabilities.
Our "platform" offers SAML Service Provider capabilities, and we have some customers that provide their own SAML IDP and Identity Store. We have other customers that use different single sign-on technologies, such as oAuth, OpenID, or third-party Web Services. Some customers use a combination of these technologies.
The goal of the proxy would be to standardize and reduce the complexity of each customer's SSO integration on the platform. Currently, we're required to customize each implementation between the platform and the customer's Website(s).
I'm having difficulty finding frameworks, libraries, or functions for proxying between SSO protocols such as SAML and oAuth, or SAML and a third-party Web Service.
I'm wondering if anyone has experience building something similar and can recommend solutions that worked for them.
I've put together a diagram that illustrates what we're trying to accomplish below.
Check this Bitly project on GitHub:
https://github.com/bitly/oauth2_proxy
It supports multiple identity providers
hth
Related
I am looking to implement single sign on functionality into an existing Asp.Net MVC 5 web application using SAML 2.0. My team and I have looked into a few different NuGet packages to help us get started with this implementation. We already have the IdP and metadata file, but now just need to implement the SSO functionality into our project.
We came across the Microsoft.IdentityModel.Tokens.Saml package and were interested in using this to set up our SAML configuration but have not been able to find any documentation on how this is actually implemented. I was wondering what is this package typically used for and can it be used to handle SAML requests and responses for the implementation of SSO functionality into a web application or should we look into using a different package? Thanks!
This package is for handling SAML assertion security tokens. It's not for handling the SAML SSO protocol. The WS-Trust protocol supports a number of different security token types including SAML assertions. The Microsoft.IdentityModel.Tokens.Saml package provides this support. SAML SSO also uses SAML assertions but is a completely different protocol from WS-Trust.
You'll find there are a number of open source implementations of the SAML v2.0 specification as well as our commercial offering.
We are an ISV building an enterprise SaaS product.
We would like to enable our customers define their IDP SAML configuration.
We are a startup and would like to support SAML as lean as possible.
1. What is the minimal configuration needed to support the major IDPs?
After reading Okta's article I understand that:
Certificate
IDP Sign-in URL
Are a must.
Say that we use a single ACS endpoint (We will implement our own logic by looking at the SAML assertion)
Is there anything else mandatory?
What about bindings? Do all major IDPs support HTTP redirect?
2. What is needed to be defined on the IDP side?
We tend to use the HTTP redirect binding, should it work with most IDPs? Is a metadata endpoint important?
As for "what is required": in many cases, you will have to generate so called "metadata.xml" file to provide the information to the vendor, so they might install a testing environment for you.
I've implemented about 5 SAML integrations with different vendors so far. The truth is that not all of them require full-fledged SAML 2.0 standard, but some of them do. I think my article should be also helpful to you https://dev.to/optiklab/working-example-of-saml-single-sign-on-integration-using-c-39mb and my open sourced SAML integration project (https://github.com/optiklab/SAML-integration-utilities) contains both Metadata File generator and C# examples for forming both SAML response and assertions. They proved to be working with many vendors, like Ping Identity, etc.
Let me know if you have more specific questions.
I am currently integrating SAML with a custom Java web-app in order to put it behind Okta. I want to use the SAML Java Toolkit that is provided by Okta.
There are many examples on the internet of OpenSAML implementations in order for me to get a general idea of how to begin. However, I am wondering if there are any significant differences between OpenSAML and the SAML Toolkit provided by Okta.
Thanks!
OpenSAML is a set of open source C++ & Java libraries meant to support developers working with the SAML protocol. The current version supports SAML 1.0, SAML1.1, and SAML2.0 protocols. In other words, OpenSAML is a library for handling the low level SAMLx.x protocol implementations.
SAML Toolkits are mostly free and open-source, designed to shorten the development time and reduce the complexity to implement SAML2.0 enabled web-apps.
SAML Java Toolkits from Okta uses OpenSAML Java libraries to implement minimal features of SAML2.0 protocol for vendors to quickly deploy SAML Service Provider (SP) server and protect their web-apps. Otherwise, vendor has to employ developers who has to know and understand SAML2.0 specification and then use OpenSAML or other similar libraries to implement SAML2.0 protocol to protect their web-apps.
I am looking for an SSO solution that can be customized according to our needs.
From what i saw over the internet it seems that Shibboleth and JOSSO are solutions that just need to be installed and configured. My question is to what extent can they be customized to use with web apps.Please consider following points.
control over cookies and session management
integration with existing authentication mechanisms being used for the app (e.g. two factor authentication)
collection of data from the user at the time of registration.
Suggestions on any other frameworks and approaches are welcome
I am looking into options for implementing single sign-on (by which I mean a single set of user credentials authenticating against a single, shared, identity store) across a range of websites.
All of the websites nominally belong the same organisation (and so we can assume a trusted relationship between them), but are hosted on different domains, and span different technologies - inc. .NET, Java and PHP.
We are consolidating all user profiles into a single back-end CRM system, and need some way to provide robust access to this for all current (and future) web properties.
We have a nascent SAML provider running, and the default option is to extend access to this across all the (currently) unsupported properties. Is this the best option? All the online references to SSO products (CAS, CoSign etc.) seem to be very old (2004+).
Have a look at Microsoft's ADFS v2.0 which support .NET
There are commercial products that do this e.g. PingIdentity, and open source ones e.g. OpenAM.
These products all support SAML.
For Java, put something like OpenAM in front of it or use the OpenSSO / OpenAM fedlet.
For PHP, use simpleSAMLphp.
The keyword to use to get current references would be something "SAML federation".
Refer SAML-based products and services
Use of the SAML protocol here makes a ton of sense. It could even allow you to federate with cloud-based services if/when your company decides to go that direction.
SAML does not require the target servers (aka "service providers" or "relying parties" in MS parlance) to be referenced using a fully qualified domain name with a common DNS root. It is also technology agnostic so it really doesn't matter what HTTP stack the service provider is running.
I'm not sure what interfaces are available to your back-end CRM system, but LDAP or SQL connections are typically used to get identity claim information and build the SAML response.
A few Identity Provider products you may want to research include Microsoft ADFS, PortalGuard (for whom I work) and Ping.