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.
Related
My question is how a 3rd party developer would login users through my Identity Platform? I looked at the documentation but found nothing.
Essentially I want to use Identity Platform as an OIDC Provider, but I don't know if that's supported.
Cloud Identity Platform is based on Firebase Auth product (literally because the documentation and the Javascript to add are still in Firebase perimeter!).
This product allows you to delegate the authentication to a third party, either Firebase auth if you use login/password authentication, or to connect Identity Provider (IdP).
There is several built in IdP like Google, LinkedIn, Facebook, Twitter,... and you can add custom Auth0 provider (SAML) and OAuth2 provider (OIDC).
The platform only allow you to perform an authentication and then redirect the user to YOUR app. Then, it's to YOUR app to ensure the correct authorisations and roles of the user.
All of this for saying to you:
Think about firebase Auth feature: originally, it has been designed to authenticate user that wants to connect to Mobile App, on Android. Today it's the same thing but, in addition, for your web app
It's designed for YOUR application with YOUR roles and authorisations. By the way, if your target is to allow your 3rd party developers to log into Google Cloud console thanks to this authentication mode, it's not possible.
But, stay tuned, awesome things are coming soon on this field
John is right, more details would help. But if I had to guess you are referring to the fact that Google Cloud Platform IAM does not handle Identity part only authorisation. You could, however use G Suite or Google Directory Sync (which can integrate with LDAP server or Active Directory.
You can refer to the link below which shows you how you can integrate with OIDC:
https://cloud.google.com/solutions/authenticating-corporate-users-in-a-hybrid-environment
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).
I am currently working on a single-page web application. The web app will make calls to a REST-like API for authentication and data storage. We are currently in the middle of securing the application, and have worked out a strategy securing the site so only registered users can gain access. But one thing we also want to do is securing the API from others to write their own applications, or access it in any other way than through our web application. The problem from my view is that the API will be open for everybody and not only for my web application.
Anyone who knows how to do this, or who can point me in the right direction. Because right now, don't have a clue.
Considered using certificates and validation?
Your API should only be accessible, if the session of the client is authorized. That's pretty much anything you could do.
There are complex approaches like using client- and server-side encryption or something really basic: render a secret in your webpage that validates the user again on every request.
You could check the headers, where the original request comes from. And so on...
But as most of that is public in a users browser, anyone could read it and adopt it in a third party app.
So save yourself and the people that really want to do a third party app some time and provide a public API :)
Simplest way will be to use OAuth 2.0 ( supports both authentication and authorization) which you need.
Also ensure you secure the data on wire using TLS (HTTPS) and any of the options below
1. HTTP Digest
2. OAuthn 2.0
3. Certificates ( Shared secret)
Stick to HTTPS+Oauth2 for now.
You could lock down your you API to accept requests from known IP's. Also depending on how your network infrastructure is designed, your web application can sit in a DMZ and your API on an internal network accessible only by servers in your network, one of which will include your backend API (This article here info https://www.digitalocean.com/community/tutorials/5-common-server-setups-for-your-web-application has some tips). For better security, a secure network design in addition to an application security framework implementation like OAuth2 and HTTPS (mentioned above). For API's, I've found that resource based authorization works better than role based authorization. Lastly, constant review of your security setup is vital as things change all the time. A good approach to this is Threat Modelling described by OWASP here https://www.owasp.org/index.php/Application_Threat_Modeling
We're in the early stages of designing a RESTful/resource-oriented web service API for a computational lingustics application. Because many of the resources we plan to serve are rights-encumbered, a key design decision has been to specify the platform so that each resource provider can expose their own web service that complies with the API spec. This way, the rights owner maintains control over their content (and thus the ability to throttle or deny access at will) and a direct relationship with the consumer, while still being able to participate in in the collaborative network.
At the same time, to simplify the job of writing a client for this service, we want to allow a client access to the distributed service through one end-point, with the server handling content negotiation and retrieval from the appropriate providers.
Right now, we're at an impasse on authentication/authorization schemes. One of our number has argued for the (technical) simplicity of a central authentication registry, but others are concerned about the organizational complexity of such a scheme.
It seems to me, based on an albeit limited understanding of the technologies, that a combination of OpenID and OAuth would do the trick, with a client authenticating with the end-point via OpenID, and the server taking action on the user's behalf with the various content providers using OAuth.
I've only ever seen implementations (e.g. stackoverflow, twitter, etc.) where a human was present to intervene, and I still need to do more research on these technologies.
Would a scheme like this work for an automated web service, or would it make the client too difficult to implement and operate?
OpenID does assume the user is present to drive a web browser to interact with their OpenID provider and do that initial authentication. But you could have the user authenticate to the end-point with OpenID, and there get an OAuth authorization for their client's automated use.
You should be able to do this without making the client too difficult to implement, particularly if the client is on a platform that allows it to spawn a web browser to drive that initial OpenID bit.
I'm going to be developing a REST-ful Web Service for a new public website. The idea behind the web service is to have 3rd parties develop fully functional UIs for the business logic.
For security reasons, I'd like to avoid users having to give their passwords for our service to the 3rd party applications. (Perhaps this shouldn't be a big concern?) Instead, I'm looking to implement some sort of login system on our site that provides an auth token to the 3rd party app but keeps the actual password out of their hands.
This made me think that OpenID might be a potential solution here. It seems to me that it should work: the actual password is handled by the OpenID provider and so it doesn't rest with the 3rd party app. I think that the trouble would probably lie with the various passthroughs, but that should be manageable.
However, there's a surprising lack of Googleable info on this, so I'd like SO's opinion. Has anyone implemented a similar system before? Is it even possible? Is it worth the trouble?
I agree completely that what you want is OAuth; I say that having worked on both OAuth and OpenID systems. I've also been in your boat a few times, having to develop a REST web service api.
For a really good ideas on OAuth, and why it is what you want see these attached article:
These are must read, there are four parts read them all:
http://hueniverse.com/oauth/guide/
the RFC, read after reading above as it can be a little daunting for most:
http://oauth.net/core/1.0
And then finally maybe some code. I have a couple projects hosted that are using Java/Groovy to do OAuth. One is a plain old OAuth client, the other is a client for specific interactions with NetFlix.
http://www.blueleftistconstructor.com/projects/
If you are relatively inexperienced with REST (you haven't built a full scale web api yet) I would recommend that you buy (or better get your boss to) "RESTful Web Services" by Richardson & Ruby. It is an O'Reilly book. I can say that it is one of their better books to debut in the past few years.
It might also help to look at some RESTful OAuth based APIs. The NetFlix API is a perfect example: http://developer.netflix.com/docs
Good luck and happy coding!
So far, I've found 1 worthwhile link:
http://markmail.org/message/utf7js473zqv45hv
This conversation mentions something called "OpenID Exchange" which is right up my alley... but the included link is broken and there's not much solid information on Google for it.
Looks like OAuth might be the ticket: http://oauth.net/
We have been working on a project to integrate OpenID Authentication for SOAP web services. You can find our project at http://code.google.com/p/ws-sandhana/.
You can provide Single Sing On to your web services using OpenID authentication and you can enforce the trusted OpenID Providers and required attributes of the users by defining service security policies.
This is an open source implementation on Apache Rampart which is the security module for Apache Axis2 web service engine. You can find our blog at http://sandhana-project.blogspot.com/ for more information.