What is the best way to use live id authentication with azure based asp.net mvc project? - asp.net-mvc

What is the best way to use live id authentication with azure based asp.net mvc project?
I find the options
1) With in Live SDK, there are options like REST, JavaScript, C# etc.
2) Since my project will be hosted in azure, there is another way "Securing Web Applications with ACS" http://msdn.microsoft.com/en-us/library/gg185928.aspx
Please suggest the design and also support with pros when an particular approach is good.

You definitely want to work with ACS. Not only is it intended for this purpose, there's a fully worked up example at
http://msdn.microsoft.com/en-us/library/gg185975.aspx
which will give you a flying start.
ACS, and Windows Identity Foundation in general, lets you take the approach of separating identity verification from your application altogether. This saves a ton of code and means that you have much less "plumbing" to support.

Related

Looking for a secure and robust STS implementation

I am faced with a project that uses custom authentication via a WCF service that returns a set of claims based on some data identifying a user, close to user name and password. Then on top of this, I have a custom STS, derived from Microsoft.IdentityModel.SecurityTokenService, that resides in an ASP.NET web site project. This project looks like it was created with the VS2010 template, and not carefully had-crafted.
My gut feeling, and lots of on-line advice tell me that this web site STS project is very far from production ready. I am now looking for an MVC based STS that I can use in anticipation of being production ready. TinkTecture's IdentityServer looks promising, but it is so much more than simply implementing a custom derivation of SecurityTokenService, I have no idea where to start. If somebody could steer me toward an open project or walk-through that does this, or offer some guidance as to where and how I can start extending or modifying Identity Server, that would be great.
Have you looked at Thinktecture.IdentityServer v3? I'm at the moment using it and very simple to use.
It is still in Beta but RTM will be available soon. It has good documentation and samples too.
https://github.com/thinktecture/Thinktecture.IdentityServer.v3/wiki/Getting-started
https://github.com/thinktecture/Thinktecture.IdentityServer.v3/wiki
Update:
Identity Server 4 is also available. It supports cross-platform deployment with .NET Core.
https://github.com/IdentityServer/IdentityServer4/
Have you looked at the MSDN article by Michele Leroux Bustamante?
It's a little old and based on WCF, but it has code accompanying it.
Building A Custom Security Token Service
If you want ASP.NET based example, Microsoft published this:
ASP.NET Security Token Service Web Site
There's also this STS project on CodePlex.

Best API Strategy for nopCommerce 3.x (MVC vs WebAPI vs ServiceStack)

We are trying to determine the best approach for adding a complex API layer to a modified version of nopCommerce. To back up a step, we're building out a custom site for a fashion/apparel manufacturer that has a lot of front-end application requirements and also needs to integrate with their cross platform apps (iOS, Android, Windows) which we're building with Xamarin. We've tentatively decided to start with nopCommerce as the base of our application to which we will add an API layer.
What we are unsure about is what is the best approach for implementing this in nopCommerce (or other similar .NET package)? The options we are considering are MVC vs WebAPI vs ServiceStack. We've been going thru many of the tutorials on PluralSight.com to get up to speed on app dev and API creation best practices, but there seem to be so many options, we're not sure where to start. We seem to be somewhat lost in a sea of implementation options for the API and how each is to be evaluated based on choice of the JS packages/frameworks used on the front-end for the web site and the tools chosen to create the apps.
If it matters, our basic requirements are:
Expand core of basic e-commerce package with some custom ERP style functionality
API layer that can work effectively with both a web front end (possibly as a SPA) and all cross platform apps built using Xamarin
Insure OAuth authentication across all interface types so we can just use social media logins consistently everywhere and can authenticate the user in any environment
Given this...
My question boils down to which of the three API methods (MVC vs WebAPI vs ServiceStack) is best for this?
In my humble opinion you should go with service stack, it´s easier to implement and a lot more flexible than web api, you can add/remove plugins for different functionalities you get a lot of infrastructure code OOB such as mechanisms to handle cache, loggers and other not just related to infrastructure such as validators and IOC container, etc.
you'll get a single mechanism for authentication including custom auth, oauth, oauth2, etc which works for linked in, facebook and google +, in that situation you´ll find yourself reusing a lot of code in across all your apps.
One other thing that I like about SS is that practically is just you and your IOC, nothig else, everything is quite simple to understand and to implement (there could be more than one hidden option or configuration you may miss in the documentation but you get a lot of support from the community in google groups or stackoverflow)
its easier to test (Unit testing) you already have abstractions for httprequest and httpresponse and a lot of more, you won´t find yourself doing wrappers for all the legacy web impl that are shipped with mvc.
SS is better than mvc web api in terms of performance, it got one of the fastest json serializers out there for .net
I´m working on a SPA app for the time beign and I have no regrets about my desition to get into the SS framework.
just my 2 cents.
I would say Web API is best option for the Services Layer
- http://www.asp.net/vnext/overview/aspnet-web-api
There are many advantages
- Web API has been in release cycle as separate component with latest features
- Security
- Versioning
- Attribute based routing
- OData integration

Advice on SSO solution for cross platform and domain sites

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

dotnetopenauth versus WIF

I need to add social media login capabilities to a site and got stuck a bit, mostly because of the, more or less, non existing beginner documentation regarding these two.
I grasped the basics of DotNetOpenAuth by checking nerddinner but some here suggest WIF so I started looking into it. I realized quickly that just getting clear info explaining if this is feasible at all on shared hosting was not easy. I don't really want to pump through all reference knowledge, technical overviews (checked some out anyway), but just to be able to see the basic functionality.
So my questions are:
Where can I find any tutorials showing the basics and bare minimums needed for WIF to function in an explanatory manner? Preferably setting up WIF in a single MVC site combined with local authorization. Is there any step-by-step documentation at all?
Is WIF feasible, at all, on a single site or would the best option be to find other solutions like DotNetOpenAuth or use the separate APIs? When trying to get to the bottom of this, I have only found information regarding the value of WIF in large, multi-application, and platform environments combined with AD / ADFSv2. Which is completely outisde the bounds of what I need.
When I look at information on WIF, it's mostly linked to ADFSv2 and STS. Is this possible to implement at all for deployment on shared hosting for example?
Any input on the matter is appreciated.
WIF - see the How-to section here.
Also Get Started with Windows Identity Foundation (WIF).
Your best bet is probably to use WIF / ACS. Good link here or look at Windows Identity Foundation (WIF) and Azure AppFabric Access Control Service (ACS) Content Map.
The other way is to add OAuth2 to a custom STS. Refer Identity Server for a really good example of this.
DotNetOpenAuth definitely works on shared hosting, and requires no set up on the web server at all (it's just a .dll in your web site's Bin folder). Depending on the social networking sites in particular that you want to hook up to, it can be just a few lines of code to wire everything up if you're hooking up to OpenID enabled sites.
If the sites you're hooking to use OAuth or OAuth 2, there is more code to write for each individual site to work against their particular proprietary API, but that would also be true for WIF unless they have code to support specific web sites that happen to align with your own.

How to integrate Azure ACS with local (custom) STS?

What would be best practice to integrate Azure ACS with local custom authentication in ASP.NET MVC application running on Azure? So basically the requirement is that web application must have custom authentication and must also support main identity provides.
I think the best approach is to use Azure ACS (to nicely support main identity provides) and since ACS in based on WIF (Identity Foundation) it would nicely fit with local STS.
What are your recommendations about this approach? Do you have better suggestions? Do you maybe have any examples how to integrate ACS with local STS?
Do I thinking wrong and those entities (ACS and local STS) are completely separated? And those are not have to be aware of each other? This would make sense to me.
I am new to the Azure ACS in WIF.
The short answer is yes, this is all possible. The "local STS" part is the one that might or might not be necessary. If you wanted to keep your own authentication, you don;t necessarily need your own STS to do so. I would start with the simplest thing possible: an MVC app relying on an STS (e.g. first a local one, then ACS, then maybe both).
There're many examples here.

Resources