What is the current, recommended way to setup a WSO2 API manager to use SSO against a Shibboleth IDP?
Our organization has an existing SSO infrastructure built around Shibboleth’s IDP which we would like to integrate into our API Manager installation. Ideal Use Case:
User navigates to API Manager Store.
User is redirected to Shibboleth IDP Login page.
If one doesn’t exist, an API Manager Account is created and assigned the Subscriber role.
User is returned to API Manager and logged in. “Signed-in-as:” renders a reasonable user name (i.e. not a GUID).
I’m aware that there is an included SAML2 authenticator component to the API Manager but it is limited in features, specifically it does not handle Encrypted Assertions, Using specific attributes for username/display name and automatic user creation.
I understand that we could write a custom authenticator, however we would rather avoid creating another code base that needs to be maintained and doesn’t have community support. If a simpler solution cannot be determined then this will likely be what we do.
What I am currently investigating is delegating all user management for the API Manager to a WSO2 Identity Server. It IS would delegate authentication to Shibboleth and auto provision users before returning to the AM. The IS seems like it could address all of the issues mentioned above.
Firstly, is this an appropriate strategy? If so, how is it recommended that the AM and IS be configured?
Should the IS and AM both point to the same JDBC Database or should the AM point to the IS’s LDAP server?
Regarding the AM authenticator which is pointed to the IS, should I use SAML or OAuth, or is there a better/simpler one?
Shibboleth IDP v2.4 – SAML2 with Attribute Push preferred.
WSO2 API Manager v1.6.0
WSO2 Identity Server v5.0.0
Here's the results of my research, for anyone interested:
1) This is an appropriate strategy. The new features in the 5.0 release of Identity Server are mainly centered around this scenario. And the 1.7 release of AM also includes features to facility this setup. Finally I've heard from the developers that they intend to push this integration even further in the next few releases.
2) As of AM 1.6 there was a bug which made it almost required to share the same Primary JDBC user store. As of 1.7 it should be more open.
There does not seem to be a preference from the people at WSO2 between LDAP and JDBC (except that the default H2 DB is not designed for production environments), however if you are choosing between installing a DB or Open LDAP for this, a LDAP server seems more suited to the choice.
3) It's best to use SAML for communicating between the two when the goal is to present the user with a UN/PW screen. When the goal is to login with pre-issued tokens then OAuth. The API Manager and IS use both protocols behind the scenes, but the answer to this particular question seems to be SAML.
In the future WSO2 plans to expand the "Trusted IDP" feature of their products, which will streamline this process (and use SAML behind the scenes).
Related
Looking for insight into a use case in Django REST Framework (DRF) and supporting customer defined authentication method: TokenAuthentication (by default), SAML 2.0 SSO, OAuth2 federated login. The method is set per customer account. I know I would enable SAML 2.0 support for all users in DRF, but I don't see how to have each user account in our software use their own Auth engine, method and settings. DRF seems to want an all or nothing configuration.
I'm aware of both django-saml2-auth plugin and this StackOverflow question SAML SSO Authentication with Django REST Framework
django-saml2-auth is a great plugin and is likely involved in the solution, but I see no examples of how to have multiple different authentication methods on a per account in your app.
More details:
I want to allow a per customer method of supporting account settings enabling the option to select one of multiple authenticate methods such as TokenAuthentication (by default), or SSO and providing SAML 2.0 or Oauth2 setting. Every account could select from the enabled methods. DRF seems to expect a single authentication provider to be enabled. Not grokking how to do this in this framework yet. Currently using TokenAuthentication as the default authentication system. TokenAuthentication would remain the default provider for most accounts. I need to be able to allow more sophisticated enterprise customers to switch authentication methodology. That's the challenge. Adding SAML2 is simple. Using OAuth2 is simple. Allow any of them to be chosen by accounts, with each account having their own authentication workflow. This is quite a different requirement than the use case that django-saml2-auth solves. That plugin may be involved in the solution, but the limitation here seems to be the model DRF uses to define the authentication provider. I've scanned the DRF, and django-saml2-auth docs, code and examples. Nothing I've seen anticipates this.
My current working theory is that I could make it possible with a little creative thinking. Perhaps there's a different URL mapping that utilizes different login/authentication method. The logged in data token that must be provided in subsequent calls could have a custom validation method that works with all supported protocols without large new blocks of code. So my instinct is the problem is mapping the login process to something that is not universal and requires some type of pre-fetching of account configuration. My proposed solution there is in the login URL for the enterprise cases. But still DRF seems to still be lacking a method for defining the authentication process per each account. Say I use SAML2 through Okta, You use OneLogin, Another person uses an OAuth2 provider, and most customers use the default native TokenAuthentication. We're all users in the same DRF app. But there isn't a way I see to define authentication engine based on account.
I know there is a possible brute force method of customizing the method being invoked to perform the login action that could be non-standard, query to configuration for a customer, then use either native or a federated identity provider. However, I'm hoping there are more DRF grokking folks that know of other strategies to enable this functionality.
I understand that there is a chicken and egg syndrome in that until you know something about the customer making the request you won't know what their configuration is. We will most likely need to support a different login URL for enterprise customers who enable SAML. That way you could load the customer's configuration. Perhaps we would do something like use a URL like so: www.myproduct/login/the_customer_company. Being new to Django REST Framework I am not super clear how to wire up different methods of authentication within the Django settings.py or urls.py? The default new user configuration would remain TokenAuthentication based but on request a customer could configure SAML and use a different URL including the company name. Hopefully my question is clear. I see how to configure DRF to use SAML SSO instead of TokenAuthentication, but I want to allow customer configured settings.
DRF and the django-saml2-auth approaches seem to be "all or nothing" and provide a single authentication provider mapping for the application. I would love to be wrong about that limitation!
One option to achieve this would be to use an Identity Provider (IdP) that can act as an identity broker, for example Keycloak. Configured this way, your Django app would be configured for SAML authentication with the single IdP. The IdP can then be configured for whatever upstream SAML / OAuth identity providers it supports depending on the customer requirements.
How you get the users to the right upstream identity provider and still have a good user experience would have a few options. The two most obvious ones would be to either configure a custom URL for each user group, and have that URL redirect to the correct IdP landing page when logging on. Alternately you could perhaps have a login page on the Django site that asked for their login / email address (without password), and when they entered that it looked up the IdP URL associated with that user and then to sent them to the right place.
While this is not a Django module / code solution for the problem, it simplifies the authentication on the Django side, and decouples the authentication to an external service specifically designed to do auth, providing the app with more flexibility (and probably more security).
I am new to this software. From what I know, the WSO2 Enterprise Integrator is come with Enterprise Service Bus inside it. But the Identity Server (IS) is not bundled with the EI.
For my current and new project, we going to be used both of it inside the architecture. Please see below diagram for more information.
Part of my project architecture
Based on the diagram, when the user is using the portal to login. The EI is serve as the middle-ware between the portal and the IS to connect to the LDAP.
Looking at the documentation, there is way to connect from IS to the other product but not vice-versa.
My question right here is how to allow the ESB to communicate to the IS and return back the message/request to the Portal.
Thank you.
Yoy did not describe your use case what do you want to achieve so I will assume you want to authenticate the portal user or manage users.
WSO2IS (and effectively any wso2 product) exposes admin services, some are common, some specific to the product. The services require basic authentication.
please see https://medium.com/#maheeka/wso2-admin-services-c61b7d856272
Another service to authenticate a user is a token service with password grant (that may be more appropriate to authenticate users and authorize requested scopes)
Just a note:
If you want to use the whole setup only only to authenticate users, then IMHO you rather may use OAuth or SAML with the IS, not passing passwords in ESB
This is a very basic question. I want to do an SSO integration using ColdFusion but do not know where to start. I found the website ssoeasy.com through a google search, but am very confused about how to use it and where to find documentation.
I think it has something related with cfldap or cfhttp but not sure what and where:
<cfhttp method="get" url="http://testsso.com/login.cfm">
</cfhttp>
It really depends on what role you want to play in an SSO ecosystem. Are you an app in a larger federation (Service Provider), or are you trying to implement an SSO style login across multiple applications that you control, or are you looking to setup so that your users can log in with Google or Facebook or such other identity registers?
A few years back we did an implementation with Shibboleth (https://shibboleth.net/) and CF where our intended place in the system would be that of a Service Provider to other companies Identity Providers. It works pretty straight forward as we let Shibboleth handle all the SAML federation grunt work and then when it's completed we get an e-mail address (the unique identifier we decided on) back from Shibboleth saying that the user has been authenticated via the Identity Provider.
Other 'SSO' implementations are around for other types of integrations.
From CFCs to handle OAuth -- https://github.com/coldfumonkeh/oauth2
To integrated oauth support if you're running a new enough version of ColdFusion https://helpx.adobe.com/coldfusion/cfml-reference/coldfusion-tags/tags-m-o/cfoauth.html
Hope this is of assistance to you.
If I understand your SSO use case, the application will be a cloud service provider (SP). There are three things you need to determine to help in the selection of the appropriate technology, mainly (1) SSO protocol to integrate, mainly SAML, OAuth, OpenID Connect (OIDC), etc. (2) Hosting, mainly Cloud, On-Prem, or hybrid, and (3) whether or not IdP discovery is needed for your business partners.
Being ColdFusion based as well as working to be a cloud SP web application, my experience is that the application is to be hosted by your organization, such that an on premise SSO capability is desired, as well as IdP Discovery will be needed for your partners.
As noted in your question there are some options for integration. I have found the most popular approach to being a SP website is to utilize a vendor product that handles the SSO protocol (e.g. SAML, OIDC) where the integration with your ColdFusion application is based upon a simple REST API integration. With this design pattern, the vendor product manages all the security of the SSO protocol and then simplifies integration to your application as a secure REST API exchange of identity information. This will minimize the impact to your application and also give the most support for modern identity. One product that offers this capability is PingFederate via the Agentless integration (also referred to as Reference ID integration). I have had much success integrating ColdFusion applications following this type of approach.
SAML seemed to be the easiest to implement for our team. Phil Duba's 2013 Beyond Encrypt() presentation is a good starting place. His website is down right now, but I'm sure you can find the downloadable file somewhere. Learning about SAML in general would be a good idea. Also, you can use Java, so maybe look at SAML/OAUTH Java examples and try doing that for Coldfusion since it is based on Java.
Everything I searched for returns info about internal user SSO, not client facing websites.
I need an SSO implimentation that works with sitecore's asp.net membership api or has it's own sitecore security provider to enable users who log in to publicfacingwebsite1.com to be able to be logged in to publicfacingwebsite2.com and logging out of one will log out of the other. I would prefer sitecore's asp.net membership provider as that will probably have the least upgrade implications in the future.
The domains are different top level domains. The websites are separate sites on the same sitecore instance.
I also need the side ability to impersonate a user (log in as the user) from an admin user, but once I have the main implementation, I'm sure I can find a method for the impersonation.
Regards
I would use a third party framework for the SSO part. For instance IdentityServer3
Here is a good introduction on how to use it together with Sitecore
In regards to the membership provider and the profile data, if you are thinking upgradeability, I am not sure it will be so, if you use the native membership provider. Sitecore will most likely switch to ASP.Net Identity in the near future. The ASP.NET Identity is supported in IdentityServer3, so you might obtain a shared user profile by using IdentityServer for the profile as well. But this is all guessing the future.
If you want to use the membership provider and the standard Sitecore profile provider, I am sure you can customize the implicit flow to map the Identity to a Sitecore user.
I have an application running on Django and a bugtracker (redmine).
I'd like to have the same accounts for my users on both applications.
So I decided to install an LDAP on my server and plug my apps on.
In the mean time, in the future I'd like to give my users the ability to attach their accounts with OAuth, OpenID (like Google, Facebook, ...).
Is LDAP still a good idea for this purpose ?
Is it something usual and how easy ?
With a unique LDAP you get resolved the duplicated account problem but you dont get the SSO or SLO functionality. The Ldap plugin of Django and Redmine are easy to configure and are well documented. Same happens with the OpenLdap server.
If you are thinking in the future, I think a nice solution would be to set a SAML enviroment.
Use simplesamlphp to build a IdP and enable the authentication sources that you want: Facebook, Gmail, Ldap, etc
Use djangosaml2 to add SAML support to django and connect it with the IdP
Use this plugin to add SAML support to Redmine and connect it with the IdP
At the end you get a system based on SAML, a protocol that actually are using Google and other big companies.