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.
Related
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.
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
Now I am creating an iOS application. I also implemented some web services. My requirement is : "The user should be able to call a web service API by Sending a Text Message(SMS)". After a lot of research I found out that there a provider called Clickatell(http://www.clickatell.com/). But I don't know how can I configure it? Please help me in configuring this. Or Is there any other APIs or SMS gateways providing this service?
Disclaimer, I do developer evangelism part time at Nexmo.
Here are a few SMS APIs that I've used (I've not really used Clickatell, but I've gone through the signup process, and the following APIs seem a lot simpler to use):
Nexmo
Twilio
Tropo
All three APIs are straight forward REST/HTTP APIs.
You can call the API directly from your mobile application, however, you should consider if you really want to then compile your API credentials into your application. It may be better to host a kind pf proxy that your application uses - here's some example code used as a verification service, but it's essentially the same concept: https://github.com/Nexmo/Verify
I would suggest to take a look at Mogreet's new Developer Web Site
Very easy to use REST/HTTP APIs and very powerful. It supports sending SMS/MMS with awesome quality for all media types.
I'm just brainstorming, and don't really know much about these technologies yet. What I want to do is provide an easy and secure for users to prove who they are across multiple web sites, and I want to provide a way for web sites to share certain information with each other (if the user gives them permission). After a little reading, it seems like OpenID and OAuth would be the best way to solve this problem (right?).
After searching, I've found two interesting projects. One is "Step2" which only has Java libraries (not a problem for me, but other, partner websites might not be coded in Java), and looks like it has been abandoned. Another is "OpenID Connect," which doesn't look like it's even been started.
So, I've guess I've got three questions. Is linking OpenID and OAuth what I should be doing? Is there a OpenID+OAuth project that has a lot of support? If not, would it be easy to integrate the two myself?
OpenID is interesting in cases like Stack Overflow where you want to let people log in with external credentials but not with the intent of exchanging data with that external site.
But I don't think you need OpenID for the scenario described... by putting users through the OAuth flow, users are effectively "proving who they are across multiple web sites" as part of the authorization process.
Describe OpenID and OAuth, how works OAuth and what does OAuth.
DotNetOpenAuth is an open source library that supports OpenID, OAuth and
support for your site visitors to login with their OpenIDs.
Document describes OAuth authorization process as well as how to work with OAuth tokens.
Also gives an overview that How to implement Google using OAuth for our web application's.
I am newbie here and confused by few things
Some websites (twitter, foursquare, etc) provide API to third-party developer to call. are those APIs the web services that the sites provide?
Are those web sites themselves built on top of those public APIs/web services? theoretically is it possible?
Comparing the traditionally built website and the websites build on top of web service, pros and cons? are there any performance, scalability, etc differences?
Thanks in advance!
I'm sure somebody can give you a more exact answer but reading your question and applying my self-taught knowledge:
The simple technical definition of Web Services according to W3C:
A Web service is a software system designed to support interoperable machine-to-machine interaction over a network.
http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/
I like to think of web services as the interactive elements of a site that its customer base utilizes. For example, Twitter's web services include: tweeting, messages, hashtags, etc. Web services are what users get to DO or DATA passed back and forth.
A public web API provides means for developers to utilize the web services on their own site. For example, Twitter's API allows example.com site to utilize tweeting, messaging, hashtags, etc from within their own domain. An API is how developers get external access to web services to make apps using those services.
I have no idea about this question. I wouldn't do that. I would use the methods the public API exposes access to. But, I've never written my own API, let alone on the scale of Twitter or foursquare.
I hope this helps.
First of all, maybe you need some more info about what an API is: please take a look at the Wikipedia api page.
To answer to you questions (these are only general thoughts and not best practices):
An API, in this case, is a way that a developer uses to access a webservice, and it's not the service itself.
The websites you mention are not using their own APIs, as these APIs are meant for remote users (clients), and offer limited data sets, while the websites need maximum performance, access to the full database, and (almost) always use server-side code. The websites you mentioned, probably use other, server-side, high-performance APIs.
See the previous point: although it depends highly on which APIs you use, what you call "traditionally built websites" (that is, web applications using server-side APIs) can afford higher performance than websites totally built on top of remote APIs, because they do not depend on the bottleneck of the network connection (because, again usually, the web server and the database server either run on the same machine, or communicate faster than the client's browser and the server).
The reason that would make most people choose to develop a webapp the traditional way is that free APIs provide limited functionality (e.g. Google custom Search, limited to 100 reults).