SaaS provider wanting Single-Signon, do I need to integrate with several Identity Providers? - single-sign-on

I work for a SaaS provider that is wanting to SSO enable our application to enterprise customers with our application acting as the service provider.
I understand the concepts behind what needs to happen and that SAML is an appropriate solution for what we are looking to do. Looking at bigger SaaS providers (slack, dropbox, new relic etc..) I can see they typically seem to integrate with a number of Identity Providers such as OneLogin, Bitium, Okta, Ping Identity etc... along with generic SAML support
As a smaller outfit we don't have the resources to partner and integrate with multiples of ID providers and to continue to add to that list as new providers emerge.
My question is that in order to provide SAML support in our application do I really need to have integrations with multiple IDPs or can I rely on a generic SAML implementation?
So if for example I used OneLogin to set up Single Sign On does that only enable SSO for clients who are using One Login as their Identity Provider?

No. It is not required IMHO. As long as you are SAML 2.0 compliant (SP-Lite typically), you'll find that you'll have customers using many different commercial (and open source) Identity Provider solutions. The vast majority of SaaS vendors have not done anything specific to support different IDP implementations. The SaaS supports the SAML 2.0 spec and ends up having customers integrating successfully with the different (IDP) products. At that point they claim to "support" the different providers.
Adhere to the spec as best you can and the rest will take care of itself.

Related

SSO - Many-To-One recommendation

for an application which offers the integration of one SSO solution, we need to add multiple SSO "providers".
One connection which authorizes the employees working in our company and multiple others which authorize each of our customers, which should have access.
Is there any self-hosted or saas solution providing something like that?
As I understood the identity broker services I had a look at, they provide a solution as Many-To-One.
I would like to find a service, which works as a broker between the application and different sso sources (e.g. AzureAD, local AD, LDAP, ...).
There are a few services available as far as I know.
WorkOS
SAML Jackson from BoxyHQ (Open-source and Self hosted)
Datawiza
The above services support multiple IdPs such as Okta, OneLogin, Azure AD, JumpCloud, etc.

How might I apply multiple security mechanisms to a Swagger-generated REST service?

I have generated JAX-RS stubs for a REST service using Swagger and want to set up the security.
The security side is very new to me and I would like to use standards as far as possible. (In the past, for other J2EE applications, I have used Filters to handle Authentication which put User objects into a Session. As I understand it, Sessions should be avoided for REST.)
There are 4 types of user who will access the services
Customers and business partners (Authentication via oAuth or similar)
Employees (Authentication via NTLM & LDAP)
Developers (Mock authentication/authorisation of some kind)
Integration test (JUnit with pre-defined users and roles)
Is it possible to define a security mechanism which would handle all of these users?
How would I use the Swagger security directives?
Am I making this more complicated than it needs to be?
You could use an open source API gateway like Tyk? Here’s a link to some handy info on API Security in the tyk docs.
And here is a blog post that describes taking a layered approach to API Security that goes beyond the gateway.
Disclosure: I work for Tyk!

SSO for Wirecloud/IdM and Moodle?

Looking for best practice instructions on how to integrate a Fiware/Wirecloud with Moodle. It would seem that Fiware/IdM should be providing the user data and Moodle connects via one of its plugins. Moodle offers a number of different authentication options (actually too many, difficult to decide best path). Ideally, once logged in, Moodle pluggins should also be able to access other FIWARE backend services.
Should be possible in principle but I notice that the Fiware academy http://edu.fiware.org/ does not have SSO with the FIWARE lab :-)
WireCloud supports using the OAuth2 token provided by the IdM to access third-party services, so the real problem is how to integrate Moodle with the IdM (as commented by #Meier).
There are some moodle plugins like auth_googleoauth2 that supposedly offer support for adding your own OAuth2 providers. Take into account that probably you will need to make more modifications to this kind of plugins as usually the OAuth provider are only used for the sign in process, but this doesn't mean that you will be able to use the OAuth2 token as valid credentials for making request to the web service API.

Build Custom SSO with SAML

Updated: Thanks for responding on my post. I am very sorry, as of today these were the requirement details. However, I can elaborate more on what I understand. I some idea on WIF, where I can write my own STS, RP and publish policies.
Couple of queries here. Do we need to have an IdP and should we connect STS to IdP. if not, can we go without IdP. I will have to use claim base authentication and federated identity mgmt in the application.we do not depend on AD/LDAP integration.
Imp Requirements are in this way. 1) we allow customers to do self registration who are direct users of this portal-M and the other set of users come from partner-X where the company claims are verified using SAML Req/Resp to access the portal-M. 2) once the direct user or user-thru-partner-X enters the portal-M, he/she should get access to another portal-N of partner-Y sending SAML request in similar fashion.
I have provided as much as details I know, since I am new to this technology of SSO/FIdM
I would happy to provide more information, if needed
Original
I have got a complex task to build a solution of externalized SSO with SAML that would be used by customers of different partners over web. the constraints are to build IdP/STS/Issuers/RP/Trusts/Policies with no open source or commercial product support choosing specific technology platforms such as Microsft or/and J2EE.
On top of these, IdP must have to use in house custom data store available on SQL Server and Oracle.
your ideas are appreciable and thanks in advance
So you want to implement a SAML stack without using any commercial or open source software?
That is a HUGE amount of work and you will need to spend a non-trivial amount of time getting your head around SAML.
In terms of a DB as your Identity repository, refer: Thinktecture IdentityServer.
In terms of SAML stacks, refer: SAML : A SAML stack .

An IdP/STS for SaaS providers, where the SaaS customer does his own user management?

(This question is not about programming, but about how to avoid doing any programming. Also, lots of terminology in here-- I'm assuming someone with an answer will already know what they mean.)
Background: I'm working on single sign-on in an environment with 'federated identity'. We have several products that are federation-aware (using, e.g., WS-Federation or SAML protocol, implemented with, e.g., WIF on .NET and Fedlet on Java), and they are offered to customers using a SaaS model. Many of those customers don't have their own store of usernames/passwords, so they will not run an "identity provider" themselves.
Question: Is there a product out there that
can be installed at the SaaS provider;
plays the role of an IdP/STS (i.e., identity provider in a federated enviroment) to the SaaS-provided applications;
has its own username/password store, separately for each SaaS customer ("tenant");
allows the SaaS customer to do his own user management, without requiring assistance from the SaaS provider.
(We could build this ourselves, e.g., as a custom STS on top of WIF with user admin screens, but we're trying to avoid that. It's not really our core business.)
Have you had a look at Google app engine ?
They support SAML, so you can use them as your Idp.
So we did not find a product that fulfills all these requirements.
What we decided on was to use AD FS 2.0 as the SaaS IdP/STS, store usernames/passwords in AD (making the SaaS customer name part of the username), and customize the AD FS sign-in page linked to a custom web application for user management and user self-service.