I am wondering if some authentication can be used to authenticate logins in Windows, Linux, Google Apps and Apache hosted web applications.
Ideally, I would love the authentication to have these features:
The authentication provider should be replicated, maybe one mirror exists online for external applications while an internal mirror is used for intranet/PC logins.
The authentication service should not be hosted on Google Apps or any other service, it should be under my full control.
Fault-tolerant, those mirrors can be specified in some order, if one fails, the next is tried.
I have done a lot of research, it seems Kerberos fits my needs. It seems that a lot of work has to be done.. especially for Google Apps, an SAML authentication service must be written.
I am wondering if there is an easy way, or if Kerberos is really what I am looking for.
RADIUS is another protocol choice. Plenty of providers available.
Just so you understand, what you are asking for is non-trivial, and unless you understand this space well (and I'm guessing you don't seeing as you're asking...), you almost certainly are underestimating the cost and the effort.
Kerberos is a large and complex specification, and getting effective interoperability across systems will cost you $$$$.
Related
Here's the environment:
Existing .NET B2B application with multiple, external corporate customers. The service provider application is hosted in IIS.
Existing non-SSO authentication with user account info stored in a database.
Must have both SSO and non-SSO login capability.
The initial identity provider will be ADFS hosted by a customer.
All options are on the table. I'm open to cloud solutions, open source (Shibboleth et al), local ADFS server, and/or custom implementation. I'm looking for the easiest and fastest way to implement an SSO solution into an existing .NET application.
Lots of things to wheigh in. First strike the custom solution part, hard and unnessecary in this case.
As I understand you are looking for the SP part as IDP will be ADFS at customer.
In this case the product does not even have to talk to the database. Only the IDP needs that.
Some things to think about when choosing the product.
Opensource is cheep in licens cost. enterprise products can be quite expensive.
Enterprise product might have better support then opensource when things doenst work. If your applications ar critical this might be important.
It might be a good idea to consider one of many cloudbased SPs to offload the management of the SP from you.
These are some considerations to take. What you choose will depend on your need and wishes in terms of uptime, support, managements etc.
Most products will have no problem implementing this use case.
I have a WebAPI back-end for a mobile, and want to host it in Azure.
I am having a hard time figuring out the real differences between AMS and Websites.
All the articles I read about the subject talks about changes and benefits in general, and I want to understand specifically which new features AMS provides, and the benefits of hosting in AMS.
Authentication
In AMS I see the "IDENTITY" tab in azure portal. From what I understand, those 3rd party configs allow me to authenticate my users easily with google,FB etc. But this is just making the process more convenient and configurable via UI. In Websites, I can achieve the same functionality pretty easily using code from ASPNet.Identity and OWIN libraris.
Push Notifications
Again looking at AMS in the "PUSH" tab, I can see two mechanisms. The Notification Hub and 3rd party section.
The Notification Hub is nothing special to AMS, and I can get the exact same functionality when hosting in Websites.
The 3rd party section allows me to configure credentials to push services from Apple and Google (APNS,GCM...) and together with libraries in AMS namespace I can easily write code to communicate with those services.
But When hosting in Websites, in my back-end I can use open source libraries. For example, Moon-APNS to talk to APNS.
Scale
As far as I understand, both Websites and AMS allows the same scale functionality (One calls it Units and the other Instances).
Are there any big differences I missed?
Are any of the claims I made are incorrect?
It would be great if anyone could shed some light on the matter, specifically addressing all the 3 issues (Auth,Push,Scale).
That's a question I often get when I present Mobile Services at user group events.
For a .NET developer, there's nothing really special about Mobile Services since everything it offers, you can do it with a Website.
Mobile Services really shines for non .NET developers since you can have a complete mobile backend by writing scripts running on Node and Mobile Services abstract all the database and REST complexity.
I will likely get downvoted since I'll express a personal opinion but anyways: I see no obvious reasons for using Mobile Services if you're coding a .NET backend.
I think you are exactly the target customer for Azure Mobile Apps. You will get all of the power of having your own Azure Website (now rebranded as Azure Web App), with the additional convenience and client libraries of Mobile Services.
One feature of the client library that you may not have noticed is the cross-platform offline data sync capability. That's usually hard to build on your own, and we have an implementation that's conceptually consistent across all client platforms. (Plus, if you use Xamarin, you can share code between your client implementations.)
To be clear: Azure Mobile Services is NOT deprecated, and will not be until long after GA (general availability) of Azure Mobile Apps. Azure Mobile Apps is currently in preview.
The other big benefit of Mobile Services that you haven't mentioned is the client libraries for Android, iOS, Xamarin, and Cordova. If you already have a REST client library in your app and don't need to worry about multiple client platforms, then Azure Web Sites sound like a good way for you to go.
AMS by itself is built on top of Azure Websites. So you can actually implement everything in an Azure website that is available in AMS.
However, the good thing about AMS is that it allows you to quickly build the backend for a mobile app with CRUD operations, authentication/authorization and also provides client side libraries for different type of clients e.g., HTML, C#, etc. so we don't have to manually make the HTTP calls.
If you have need to implement the above functionality in Web API, it is quite an effort. Isn't it?
I wonder what is the security level for azure hosted websites. Is it Medium/High or Full?
They run in Full Trust (source).
However, they use a Sandbox mechanism, and as a result some APIs are not available (e.g. Sockets using IPv6), or do not work as expected (for example, the Socket.Available property is unavailable, which restricts the use of some libraries such as NetFTP).
If you are considering using WA Websites for scenarios in which .NET Security might be a problem, I suggest you to get in touch with Microsoft support to ensure that the specific features you may need are supported on this environment.
I've recently been asked to redevelop an .Net 2.0 WinForms application with a back end SQL Server Express DB.
One of the requirements is to allow remote users access to the application, so I've been considering hosted options to avoid VPN setup. The data is not sensitive and does not fall under data protection act, so a basic security approach for the web will cover me.
I like the idea of using Azure for a few reasons, but I'm not sure if a good fit for a users base of 5 or 6 with no real scope to grow. I've never used Azure and I plan to develop using MVC and a SQL backend as this is my main skillset.
A few points in favour of Azure in my mind are:
Tight integration with the TFS preview that I'm using for this project
Easy to setup a sandpit and a live version
Easy maintenance as I expect other hosted options will require more knowledge of underlying OS
Sticking to a full Microsoft stack should hopefully make things simpler
From what I find on the Azure site the message is all about scalability, which is great if you need it.
My question is simply, do you need a large user base, or plans to grow quickly, to use azure or is it how we should be hosting apps now?
What you're asking here is the perfect case for Windows Azure Web Sites:
You get 10 web sites for free (no custom DNS, but this is perfect for your 'sandpit'/test version). The shared mode supports custom DNS and is very cheap.
Tight integration with TFS preview and GitHub
You don't need to worry about the underlying OS, you simply publish from Visual Studio or with TFS Preview.
Sticking to the Microsoft stack is the easiest solution, but other technologies work great aswell. Since you're talking about MVC I'm assuming you are considering ASP.NET MVC, which is a perfect match with Windows Azure. Take a look at the training kit for some good examples.
The day you'll need a solution which more scalable (meaning you'll have more users and more income) you can easily upgrade to a reserved instance or to a Cloud Service (Web/Worker Role).
About your question: "My question is simply, do you need a large user base, or plans to grow quickly, to use azure or is it how we should be hosting apps now?"
Windows Azure is a cloud service platform (includes PaaS as Cloud Services, IaaS as Windows Azure Virtual Machines and also Websites suggest by Sandrino above), and with cloud services you have ability to start very small and grow as much and as quickly as your user requirement is, so you can use Azure with both cases. On the other hand there are some advantages using certain offering depend on your which service you are going to use to run your application.
I think article (Section: "What Should I Use? Making a Choice") will explain the strategy about how you make a selection among various services.
This SO discussion does talks about the difference between cloud Services and Azure WebSites as well.
I've got three different apps, all in GWT, none using Spring. Today, all of them got their own security layer provided by Tomcat. I want to setup a security layer shared by all of them. So that I don't have to deal with changes in the security layer for every app (following the DRY principle). I believe it's something similar to what Google does. Every time I try to login to any Google app, I'm taken to account.google.com.
How can I do that? Maybe setting this webapp Accounts to deal with every aspect of the accounts (log in and out, edit account, etc), and connect the session (or authentication) to my webapps?
You could deploy a Central Authentication Service and use it as an authentication provider for your applications.
Using a library (for example gwt-cas) to call your CAS will reduce your code duplication to a few lines of configuration per project.
You'll want to look into container-managed security. Here's the salient documentation.