We have started looking at this tutorial to use the new notifications hub in Windows Azure:
http://www.windowsazure.com/en-us/manage/services/notification-hubs/notify-users-aspnet/
At one point it specifies a warning stating:
"SECURITY NOTE
The AuthenticationTestHandler class does not provide true authentication. It is used only to mimic basic authentication and return a principle. The user name is required to create Notification Hub registrations. The above implementation is not secure. You must implement a secure authentication mechanism in your production applications and services."
Can anyone suggest a good way to secure this that will work from windows phone, android and iOS. We can't use the built in authentication such as facebook, google, twitter, etc. as it needs to use our own authentication backend.
Many thanks for any help.
To implement cross platform authentication it's best to use a standard like OAuth2.
OAuth2 allows you to
Handle logins in one place on server side.
Your clients only get as few account informations as needed. It's possible to hide the password from clients (whereas not common in mobile apps). Each client gets it's own unique access token.
Remove access remotely by revoking access tokens on server side.
For implementation:
Apache Oltu is a Java Framework for OAuth2 authentication (server and client support).
Udi wrote a very good tutorial for Android authentication.
Related
I develop a native android application that done it's authentication, authorization, getting resources using WebApi backend.
After many discussions about what is the best and secure way to implement authentication and authorization using .NET technologies we decided to use Thinktecture's IdentityServer3.
Before i was follow this series to implement a token based authentication using Asp.NET Identity system, every thing was OK but after investigations i decide to decouple the authentication server and using Thinktecture's Identity Server.
So now i have a separated web apps hosted on azure one for resources and other for authentication using IdentityServer3 and one native Android client .
My Android client application having an authentication using Facebook/Google, and i already implemented this before on android using Parse or separatly based on Facebook Android SDK & Google services
Also Users having roles.
Now i want to know if there is a correct approach for doing that from the authentication server perspective and also client android application perspective as there are many discussions about the configurations of identityserver3 with native apps also should i use a webview activity in android to handle connection with authentication server or using native java code with HTTP library like retrofit to send request and get response.
Also with Facebook, i already implemented authentication directly from android app using Facebook Android SDK and i can get the AuthToken and the approach that i think about is like shown in this question:
Authenticate user to Facebook from Android application.
Get the FB auth token to the android app.
Forward the authentication token & facebook UID from Android to web
server.
On web server, make Facebook API call with the submitted token.
If the Facebook API call from web server returns valid authentication, and the user id is equal to the one submitted by Android application, your server can trust the id (& you can be sure that the Android authentication real)
Or should i depend only on backend identityserver to handle Facebook authentication?
you can use the hybrid flow (if you need access tokens and refresh tokens)
, also You could use the implicit flow
just have alook at this topic
and about how can you do it,
Either, you can do it by doing a combination of web views and hybrid/implicit flow, or do the redirect style to the IdSvr login page. Using resource owner password flow
We are building a web application that also includes webAPI's. These WebAPIs needs to be exposed to other applications as well (other internal application on different subDomain or 3rd party application). We are thinking of using OpenId Connect, so that not only we will be able to give access_token but also id_token for authentication.
Now the question is 'Should my main application also use openId connect' for authentication/authorization. I am not in favor of this. As per my understanding, only external applications should use openid connect to use main application's resources. And internal applications (main as well as application on different sub-domain) can work with regular cookie based authentication.
For instance, main application is MyWebApp.com (this includes webapi as well). Other internal applications are maps.MyWebApp.com, admin.MyWebApp.com, payroll.MyWebApp.com.
Other 3rd party application could be OtherWebApp.com.
Please suggest.
"Should my main application also use openid connect?"
Advantages
- paves the way for single sign on
- modularizes your authentication so you're not implementing different authentication solutions.
- you have the option of using the same Web api from your main app. (although you could just use the oauth2 client credentials flow and simply skip the openid connect authentication part)
Disadvantages
- if you only had one client app then this could be overkill
- you're adding complexity to the app by making it depend on an authentication server app (but modularizing has advantages too)
I don't know your scenario completely but I'm inclined to say yes. Although, I'd definitely turn off the consent screen from oauth2 for your trusted main app. If you don't use openid connect for authentication, it shouldn't be too hard to convert your main app to use it later
My scenario is that I have to expose some API over WCF to third party clients. I wanna use the most secure option. Ideal solution would be making a windows account for each client in my server active directory and letting them access the service with Transport & Message security and Client credentials username. So I could ask the client to provide username and password and use windows group policy to role base authorization.
Since this is an internet facing WCF service, I'm not sure I could use windows accounts??? Should I be using database solution to manage usernames, pwd and roles?
Should be able to consume from .NET clients as well as Java clients. Third party clients could be anything that can consume soap.
What's the best security option to this scenario? VPN is not an option as this totally should go over internet. Your help is very much appreciated.
It sounds like what you need is some kind of a token based authentication setup. Microsoft seems to publish the best material in the game for this kind of thing. You can find their articles here and pick the scenario of security that most closely matches your needs:
Microsoft WCF Security
you can use ASP.net membership with form authentication for your service.
using windows authentication for internet facing service is not a good idea.
for more information:
How to: Enable the WCF Authentication Service
Windows Communication Foundation Authentication Service Overview
Securing WCF with Forms Authentication
I need to find a way to authenticate/authorize users in a WCF-service. I'm using an external authentication service which stores the credentials of the users.
Eg. "Bob uses our loginmethod, we send the credentials to the authentication service, the service lets us know if these credentials are correct."
If Bob sends another request, we need to know if Bob is already authenticated.
Now a session is being created on the client, but it needs to move to the server-side. We can not rely on clients for security.
Can this be solved by using security cookies or do any of you have a better suggestion?
EDIT! I can only use the authentication server and do not have access to it
The problem you are describing is a well-known one that had (at least) two standardized solutions.
Federation using WS-Trust
The first option is a SOAP based one that uses active federation based on WS-Trust. In this solution:
Your client provides credentials to the authentication service
If the credentials are valid, the authentication service returns a signed (and encrypted) token to the client. It is encrypted so that any information contained in the token remains confidential - even the client cannot read it. It is encrypted with a public key belonging to the your WCF service. It is signed with a private key belonging to the authentication service.
The client submits the signed/encrypted token to your WCF service. The service can decrypt it because it holds the private key for decryption. It can trust it because it is signed by the authentication service.
Based on the content of the decrypted token, the service can establish the client identity and make an authorization decision.
In this model, the usual terminology is:
Your authentication service the Security Token Service
Your WCF service is the Relying Party
your client is the Client
This sounds complex, but it is very well supported in .Net and WCF using Windows Identity Foundation. There are many samples available much of it (maybe all) can be done via WCF configuration rather than code.
This is well suited to scenarios where the clients are crypto-capable (like your .Net clients) and where good frameworks exist (like WIF). It is not so good for low spec clients such as browsers and some phones, or where you are not in control of the clients.
It is commonly used in enterprise scenarios, including enterprise-to-enterprise federation. It is used less often in internet scenarios.
the strengths of it are
It is standardised and therefore generally well supported by frameworks
It means that your WCF service never has to handle the client credentials (= more secure)
It makes it pretty easy to switch to different authentication services (because it is standardised). For example, on-premise AD and Windows Azure AD both support this, as do other independent identity services
An overview can be found here:
http://msdn.microsoft.com/en-us/magazine/ee335707.aspx
And Google will show you lots more walkthroughs and examples.
Federation using OAUth 2
In this solution:
The client displays some UI provided by the authentication service (generally a web page)
The user enters their credentials in that UI and the authentication service authenticates and eventually returns a token to the client. The nature of the token is not standardised, nor is whether it is encrypted. Generally it will be at least signed.
The client submits the token with each request to the WCF service
The WCF service authenticates the token as in the previous solution
In the OAuth terminology:
Your authentication service is the Authorization Server
Your WCF service is the Resource Owner
Your client is the Client
Again, this sounds complex, but it is reasonably well supported in .Net. Probably not as well as the WS-Trust approach though at the moment. It is supported by Windows Azure AD and on the client side, using the Windows Azure Authentication Library. May other services use this approach - e.g. Facebook.
This works well where
Your client is low spec or not crypto-capable (e.g. a browser or some phones)
You do not control the client (e.g. a third party application is accessing your service)
It is very commonly used in internet application where you as an owner of the WCF service don't necessarily know the users or the clients. It is a less complete standard in some ways (e.g. it does not define exactly how the authentication happens) and as a result, it is less easy to switch to alternative authorisation servers.
The strengths of it are:
It is simpler and therefore has wider platform support
It is growing in popularity and therefore the library support is getting better all the time
The user never enters their credentials into your UI, only into the auth server, so it is more likely to be trusted (in internet scenarios)
It has a built in way of controlling the scope of the permissions granted to the client, and revoking those permissions, so again it is more trusted in an internet scenario
The official .Net support for this is in the Windows Azure AD Authentication library
http://msdn.microsoft.com/en-us/library/windowsazure/jj573266.aspx
There are other, open source components too, such as DotNetOpenAuth
http://dotnetopenauth.net/
Which solution would be best for you depends mainly on the nature of your authentication service I would say. And on whether you are in an enterprise or internet scenario. If the auth. service could be easily adapted to be a WS-Trust Secure Token Service (STS), then that would be a good route. If adding some web UI to the auth. service is feasible, the OAuth might be better.
Or, if neither option is feasible, you could just borrow the patterns form one approach and use that without going for the full standard.
Good luck!
I need to provide a login mechanism in my application. I'd would like to provide login for the most common IPs, such as Google, Yahoo!, Facebook, Microsoft Live and others.
My application is a Desktop application written in C#, so is not a Web application.
Do you know any library or framework that I could use to achieve this purpose.
Must I implement a sign-on mechanism for each provider?
NOTE: I know that Microsoft provides a unique sign-on mechanism in Azure, but I'm not interested in this Azure service.
OpenAuth will do what you need, but it can be complicated to use. There are an abundance of resources to help you, though. Here is a link to an article describing the process of using OAuth, and there is an excellent SO answer Here with code samples you can use to get started.
You will need to register with the services you'd like to use for sign on and receive a key for them. Quoted from the linked article:
Register your app with the service that you are developing it for. e.g. Twitter, Twitpic, SoundCloud etc. You will receive a consumer key and secret.
You, the developer of the app then initiates the OAuth process by passing the consumer key and the consumer secret
The service will return a Request Token to you.
The user then needs to grant approval for the app to run requests.
Once the user has granted permission you need to exchange the request token for an access token.
Now that you have received an access token, you use this to sign all http requests with your credentials and access token.
Though you will need a key from each provider, the method of authentication will be the same, so you will not actually need to implement separate sign on code specific to each service provider.