We might want to create third party API to access our Plone CMS site data. One of possible methods to share the user priviledges in third party systems is OAuth2, as used by Twitter, Tumblr and Facebook. This way the third party gains the user priviledges after the user clicks "Allow" in the dialog for accessing one's data.
Is there an existing solutions where Plone acts as OAuth2 host (not sure about the terminology)
What other options there might be for this use case
I am not in rush, this is 2014 planning :)
As far as I know pmr2.oauth is the only package (disclosure: I also wrote this) that provide OAuth provider support for Plone (i.e. this lets Plone act as an "OAuth host", including support for scope so to let users know what they are allowing, like Twitter et. al.). There is another package that I briefly looked at called wsgioauth, but it is a fairly general package and it's for wsgi, so I ended up building my own package (and it looks like wsgioauth hasn't been maintained for 3 years now).
Currently it only supports OAuth 1.0; reason for that is that at the time of development there were no good OAuth 2.0 libraries, especially for providers. Only recently the support for RFC 6749 (the actual OAuth 2.0 standard) is beginning to surface through oauthlib, which is the library that does the signing of requests for pmr2.oauth. That said, hopefully I have it written in a way that is modular enough to plug in support for OAuth 2.0, or at least the core is easy enough to be modified to include support for this. I would be more than happy to have the Plone community to take it and improve on it (or even fork it off, or anyone knowledgeable in this area) as I don't have any immediate plans to include support for OAuth 2.0 yet.
Related
I feel a bit overwhelmed right now with how to approach building an SSO solution for a project I'm taking on. I understand that I need a centralized login site, but, I'd like input on what framework I should be using to achieve this. I've been reading a bit about Windows Identity Foundation (WIF), but, the lack of documentation and code samples is quite disappointing. DotNotOpenAuth sounds like it has much more usage by the community than WIF, but, I'm not sure if that's the right framework for me to use given that I am not going to be letting third-party accounts be used for logging in.
There are multiple user data stores to take into account as well; active directory and a SQL Server database.
I really don't care what framework I use so long as it's simple and intuitive; I don't want an overly complex solution. Documentation and samples are also a plus! I already have experience with creating custom role providers and membership providers; those were a breeze and easy to do.
Here is a very quick visual of the structure I'm dealing with:
Refer: Claims Based Identity & Access Control Guide and Identity Developer Training Kit. There's WIF samples there.
In terms of what you want to achieve, ADFS v2.0 will get you most of the way but it can only authenticate against AD. For SQL server, use IdentityServer and then federate ADFS and IdentityServer.
Have a look at SAML. It is designed to address SSO. You may also want to look into OpenID.
There are enterprise products out there, such as CA Site Minder or IBM Tivoli for this kind if thing. They are not cheap because building a custom solution for this will be quite a feat.
If you are .NET based - then .NET 4.5 (which includes WIF) is the way to go.
But the framework will be you simplest problem. Building that kind of security infrastructure is hard. Have a look at both the book and idenitity server from nzpcmad's answer as a starting point.
As far as cross-platform goes, SAML tends to lead the pack. There are many implementations (java, php, perl). As Dominick (#leastprivilege) mentioned, if every application is .Net based, WS-Fed via WIF is the way to go. (btw, Dominick is the man when it comes to WIF - definitely hit his blog and forums up if you plan on exploring that route)
OpenId and OAuth are alternatives that you will hear about. They are somewhat less secure (the trust is in the user, rather than the infrastructure) and you will find that you will have to build a provider in order to support sign-in using your own user store.
Regardless of the route you choose, be prepared to do a lot of reading and learning. Check out the wikipedia articles above for a nice overview of how these technologies work, and don't be afraid to ask questions..
I'm trying to secure my MVC4 Web Api. Actually, I just really need an identity provider with some light security. My service is similar to twitter, from a security standpoint, there's not a lot of private data, but the service does need to know the userid for the caller.
It's also important to know that the web service will only be consumed by mobile devices right now, although a website may accompany it at some future point.
S.O. and the internet have led me to Thinktecture.IdentityModel, but man it seems complex and I can find exactly zero documentation or samples. I also haven't yet had a pleasant experience with claims-based authentication. I don't have a claims server, token provider, or anything like that, and it seems like you would need that to use this method. This all seems far to heavy for my situation.
I've also read about people implementing their own HMAC solution (https://github.com/cuongle/WebAPI.Hmac) or using OAuth (https://github.com/maksymilian-majer/DevDefined.OAuth) but these also seem a bit complex (I've read that OAuth without the helper class is enough to make the best developers cry, and I'm not the best). Janrain looks like it might work, but it looks like you have to pay for more than 2,500 authenticated users per year ...
What is the best way to implement a simple identity provider and security for Web Api?
Thanks!
I have attempted to answer a similar question to this before Create an OAuth 2.0 service provider using DotNetOpenAuth where I highlighted the Thinkecture Identity Server. The Setup instructions not too difficult (IMHO) The installation video is here and should help a lot.
I have updated my older answer with this too but there is also a fairly lightweight O-Auth 2.0 implementation example here Sample code here http://code.google.com/p/codesmith/downloads/detail?name=OAuth2.zip&can=2&q=#makechanges
Have you also read this well articulated question here Authenticating requests from mobile (iPhone) app to ASP.Net Web API (Feedback requested on my design)
Well, security is hard :)
As for Thinktecture.IdentityModel -- this is a token processing library (among other things) that you'd use in your WebAPI application. You'd use this so you don't need to do the logic to accept tokens (basic auth, SAML, SWT, JWT). Claims are just a side-effect.
If you're looking for an identity provider, then the sister open source project Thinktecture.IdentityServer is in beta for version 2. It's an identity provider that supports a custom database and issues tokens. The project URL is:
http://thinktecture.github.com/Thinktecture.IdentityServer.v2/
In response to the problem of finding example code as documentation, consider the samples folder in the Thinktecture github repo: https://github.com/thinktecture/Thinktecture.IdentityModel.45/tree/master/Samples
(Why do you need more reputation to comment on SO than to answer?)
I need to build an ecosystem of online tools (these tools are on various platforms like Moodle, Website Baker, ASP.Net, php, etc, some already built, some purchased from other vendors and some to be built), where I want a single login that the end user should have.
These tools, standalone, have their own login mechanism in place at the moment.
I am planning to build a central system on DNN where users register and this system exposes an oAuth service that other systems use to authenticate users against.
I am considering DNN (DotNetNuke) platform for the following reasons:
1. I am an ASP.Net developer and familiar to some extent with DNN (Not a whole lot, but enough to know that it has the concept of providers and modules that I can customize as per my needs).
2. I will need a shopping cart and a registration system which I am hoping to get some ready-made third party solution.
WHAT I NEED INPUTS ON:
Is there some DNN component out there already that exposes oAuth authentication from a DNN site? I am looking to implement something similar to what Google has implemented for it's oAuth interface.
If I understand you correctly, you are trying to build is called 3 legged authentication with oauth where you want dotnetnuke to be the provider. In order to do that in dotnetnuke, you need to provide a UI where consumers can register and get AppId and consumerKey. Once that is done, Consumer will send user to dotnetnuke for login. Dotnetnuke will validate the user and return appropriate information to consumer.
Here are some things that can help you:
DotNetOAuth library
OAuth website
http://code.google.com/p/extremeswankoauth/wiki/Server_Examples
http://www.cleancode.co.nz/blog/523/oauth-dot-net
Example oAuth implementation in java
Let me know if you need more help.
I don't know if it is the best way to accomplish the solution but it was what I did.
There's a code sample of DotNetOpenAuth here which uses OAuth to authenticate users. Probably you will see that there are more examples, and even newer but .. pay attention because If you are using the last version of DNN (7.x), it works using the .NET Framework 4 and the newer samples uses 4.5. So, take a look of the first example! The ASP NET Handler called OAuth.ashx is your OAuth Service provider.
Then, I built a DNN module based on the sample to make DNN work as OAuth Service.
I followed this guide to build the module. There are some videos which shows the basic of module development.
Please I would like someone to tell me if dotNetOpenAuth single-sign-on.
All I want to achieve is to be able to seamlessly logging to all domains without redirect to third party system for authorisation or Authentication within a mixture programming platforms e.g (PHP or .Net)
DotNetOpenAuth library is a simple library to implement Single Sign On for .NET based application. The only issue I faced was related to performance. It was found to be a known issue with a particular API that cause the sluggishnes.
DotNetOpenAuth can be used for SSO solutions, but each new web site a user visits does need to perform a redirect to the identity provider. In a controlled SSO environment, that provider may never appear to the user, so the login is totally transparent. There are a couple of samples of an SSO configuration that comes with the DotNetOpenAuth download.
DotNetOpenAuth will help you do what you want to do provided you can support OpenID from PHP. You need to implement a provider (the site that authenticates you against a DB or other store), and a consumer (the site you want to log into).
My recommendation would be to consider the authentication protocol you wish to use rather than a specific library at first. In the case if DotNet OpenAuth it has support for:
OpenID
OAuth
InfoCard
These are just a few of the protocols available. You should also look into the SAML family of protocols, in particular SAML 2.0.
There are implementations of SAML for PHP, .NET, and many other platforms. You might want to look at a comparison between OpenID and SAML in order to choose which is better for you.
We are currently using an outdated screen scraper gem to import contacts from gmail/yahoo/etc. I want to update this to use the new OAuth based APIs so users don't have to enter their credentials on our site. I'm really intrigued by the work Plaxo is doing with Portable Contacts which Google also supports. It feels like that is a good direction for read-only access, and it is still backed by OAuth.
Are there any compelling reasons to just go with the standard OAuth API for these providers instead of going the Portable Contacts route? I'd like to know if there are strong reasons to avoid it. I'll still be using straight OAuth for the ones that don't support PC so it's not a question of development time, more one of support and confidence in the new approach.
The idea is that each OAuth implementation will be slightly different where as each Portable Contacts implementation will be the same. It's kind of like a REST API (OAuth) vs. a SOAP API (Portable Contacts --but with the same overhead as OAuth).
So you should theoretically be able to make one Portable Contacts Reader and hook it to any provider who supports it with no additional work.
In reality for now, you'll probably need to work with both Portable Contacts and OAuth-non-portable endpoints. (With most OAuth-non-portable providers hopefully moving towards Portable Contacts).
OAuth Core doesn't define either discovery (leading users to the OAuth URL which will let them authorize the resource to the consumer) or representation (informing the consumer about what authorization the token will provide). Without a spec such as Portable Contacts, these need to agreed upon ad-hoc by the consumer and provider (with discovery probably being simplified to a well-known URL). So Portable Contacts is just answering those questions once for each provider which uses them. You'll need to work out the ad-hoc answers if you want to support providers which don't, but you'll be using the same OAuth Core implementation for all of them anyway.
Portable Contacts itself builds on the OAuth Discovery spec, which seems to be expired without a replacement, unfortunately.