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

(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.

Related

Microservice Architecture design for subscription

Would like to get some opinion on designing a system with subscription model using microservice architecture.
We implemented an identity server which authenticates and authorizes
users, and stores their subscription profile. (i.e. resources they can
access like which magazine and issues)
on the resources service, the subscription profile will be used to
filter their eligibility. example, if their subscription starts from
Year 2018, then this will take effect and return only year 2018 data
to the users via REST API.
Is this a standard/proper microservice architecture implementation? or any better ways to design this?
I'd argue no, especially if you want to embrace the principles of microservices - you're storing authorization and application domain specific data in your Identity server. Your IDP should only be concerned with authentication concerns.
I'd suggest a separate service or set of services for managing and retrieving this additional information that is linked to user entities in your IDP via a correlating ID (e.g. subject ID, email address, account code etc). This service would own its own data and be consumed by anything which needs to know about subscriptions and the like.

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

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.

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 .

Confused about STS and WIF

I am building 3 new websites and want to use WIF4.5 for SSO across these 3 different domains. I have read tons of materials about the WIF, while I understand the principles and purpose of WIF I am still very confused about how it works in real life, please help me understand the following questions, many thanks.
All my sites will be hosted using shared hosting services.
Everyone is saying that there's no need to build you own STS, but if that's case where can I found external services I can use to sign in my users and what about normal user registration interface for new users? and What about my existing users?
If i only need to build claim based web applications, where do I get user identities from in a real production environment? Do I have to pay them or do they need to go through my sites to approve them?
Is it correct that its no longer possible to let user register on my websites if I use STS?
Do I need to enable SSL and buy X507 certs for all my sites if I want them to be claim based websites?
I want to have a shared user database to store all our users, old and new, does that mean I have to build my own STS?
What exactly does it take to build my own STS, can I pcik one of my websites to be my own STS provider for my own websites?
What does it take and cost to build a STS? like SSL, certs, other stuff?
Can I enable social sign-in like facebook/Google/Yahoo if my sites are claim based?
Thank you guys.
You definitely CAN write your own sts.
You can allow your users to register in your sts or federate with an external identity provider (google/facebook)
No, an sts is just a asp.net web app, users CAN register there.
No, although ssl is recommended when usernames/passwords are involved.
No, you can use an existing sts like the IdentityServer which allows you to use a custom MembershipProvider against your own database http://thinktecture.github.io/
Yes. http://netpl.blogspot.com/2011/08/quest-for-customizing-adfs-sign-in-web.html
X509 certs for token signing can be created with free tools like portecle or makecert
Yes.
Microsoft has the Access Control Service (ACS) which supports Windows Live ID, Google, Yahoo!, and Facebook logins. Unless you need to option for users to register accounts at your site that might be a good option.
If you want a (1) free solution as an STS or (2) want to have your own Id store, Thinktecture's identity server is the way to go.
I have some written some tutorials on how to do it.
http://claudioasanchez.blogspot.com/2011/09/setting-up-thinktectures-identity.html