I'm using Message/Username/Custom MembershipProvider for my WCF service authentication.
by default, WCF authenticates every call from the client.
My Custom MembershipProvider access database for checking username/password.
so for each call from the client the service has to access database for authentication, and this might have performance implications as the number of calls increase.
Is there a default way to cache this authentication information(perhaps by creating a ticket and using that ticket for further authentication as in ASP.NET)?
You absolutely could use ASP.NET Forms Auth for WCF calls, keeping the token as a cookie that's passed with every request.
Related
I am developing ASP NET Core Web API and I am confused by choosing the authentication method. I used to apply default Asp Net Identity authentication, but recently I've known about JWT. So I've implemented Authentication almost as it done in this article: https://stormpath.com/blog/token-authentication-asp-net-core.
But I can't understand the benefits of this JWT. With simple Asp Net Identity Authentication, I don't care about token storage etc. I only need to log in with signInManager and use authorized methods until logout. With JWT I need to think about the token store, expiration, and other difficulties. So, what're the benefits of this JWT? How can I store this JWT token after login? Furthermore, should I even use this JWT? In my case, I need simple authentication for simple WebApi which will be used by one or little bit more users. I've also heard about OpenIddict, Auth0, IdentityServer, so what's the difference between all of these authentication mechanisms?
This is the way I understand this, split in to 3 logical parts.
Authentication Server - this will authenticate and issue the JWT token, when the API need's to validate the token it will send the token to this server to validate it.
Client - this is what serves your web pages, or you app perhaps. This is what will need to request and store the the JWT token. The client will need to pass the token to the api every time it requests data.
API - this is what serves the information and needs to validate the token with the Authentication Server.
So, what're the benefits of this JWT?
JWT is issued to the client and stored on the client side. Having JWT allows multiple client's (App's or Websites) use the same authentication server which distributes JWT and states which API's the client's can use and how.
How can I store this JWT token after login?
I only tried to store it in an Ionic 2 app which uses angular 2 which has a storage module. But i'm pretty sure numerous people have done this already and asked this question:
Simple JWT authentication in ASP.NET Core 1.0 Web API
Token Based Authentication in ASP.NET Core (refreshed)
Update
If your front end is made purely html/js/css and doesn't have a back end to accommodate it you would store your token in local storage, there a multiple npm packages that help you with this like this one. You want to look for Implicit flow.
Otherwise if you do have a back end that comes with your front end you want to store the token in a session/database your pick, there are 3rd party providers to do this like IdentityServer4. You want to use Hybrid flow
Furthermore, should I even use this JWT? In my case, I need simple
authentication for simple WebApi which will be used by one or little
bit more users.
The reason for the whole separation of concerns is performance so you don't really need it since it's just one or a little more users. Do it because it's a learning experience, JWT is not easy to setup from the beginning and will require you to do a lot of reading and you will fail and you will be frustrated but at the end you will know how to set it up and how it works
I've also heard about OpenIddict, Auth0, IdentityServer, so what's the difference between all of these authentication mechanisms?
So what you did in the Stormpath tutorial is NOT production ready. That is just a little demo, to help you understand what JWT is and how it works. The above mentioned are complete libraries that tackle all the heavy lifting and do not require you to built the whole thing from scratch. And the main difference between them is the scope that they cover.
I personally used IS4 and it had me crying no more than 2 times (It was simpler than I thought):
http://identityserver4.readthedocs.io/en/release/
https://github.com/openiddict/openiddict-core
https://auth0.com/docs/quickstart/webapp/aspnet-core/00-intro
Use tokens (JWT) if you have multiple applications or services (web, mobile, other services) connection to your API. Benefits: Stateless, Scalability, No cookie, no CORS problems (if you allow it).
If your API will be used by only one web application use the default ASP default authentication system. Its easier to set up.
If you webapi and user interface are hosted in the same web application, token bases security does not buy you anything over the cookie based authentication provided by the built in authentication. That's because the authentication cookie gets sent back to the keep application on every HTTP request. When you make calls to a website other than the one you signed in on those cookies do not get sent. So JSON Web Tokens (JWT) provide a standard format for browser to send identity information to a website when a cookie isn't an option.
If your Web Api is to be accessed by AJAX calls then JWT may be a desired choice, but not mandatory. judging by the description of your app,it seems to me that the default authentication system can serve you well.
Auth2 is the authentication mechanism that enable external login such as Facebook. It is part of the default authentication system, and you need not do much in order to employ it in your app.
OpenIddict sits on top of Auth2. It is part of the default authentication system, and you need not do much in order to employ it in your app. It is the authentication mechanism that enable external login such as Google+
IdentityServer may be used for large Wep Api that is accessed by Ajax calls. As for instance, you can use IdentityServer to authenticate users longing to a front end Angular app.
Once again, the default authentication system can serve you well.
Hope this helps...
We are building a web application in microservices architecture.
We have a service that handles the authorization (i.e user's privileges, access credentials, roles etc...) and we are considering how to pass on these credentials in the system.
We have 2 option:
1. Sign those credentials in the gateway (auth and proxy service) using JWT and pass on all the information so every service could verify it (with its public key) and read the user's info.
2. Every service should make a request to the authorization service for querying the user's access on every action.
We are having difficulties on deciding which way is better in terms of high cohesion and loose coupling and of course making it easy for service development.
You have some other options: instead of reinventing the wheel, you can use an OAuth 2.0 identity provider/broker out of the box.
Keycloak is a free open source identity provider and broker that provides all these functionalities.
Auth0 is a managed commercial service that provides all these functionalities too.
And I'm sure there are many other services exist for OAuth 2.0 protocol.
As for your 2 options:
You can extend the JWT with your custom authorisation claims (roles or permissions) and since the JWT will be signed, then it is safe to assume the data is correct by your service. Give that the JWT is a short lived token that need to renew every few minutes.
I have several Silverlight, WP7 and ASP.NET MVC client applications Most allow anonymous access to the application but secure various features based on a user's credentials when logged in. All of the clients use a common back-end service application for data access and business processing which require the user's credentials for authentication and authorization.
We currently use Forms Authentication in all client applications and I'd like to migrate our architecture to use federated identity and a claims-based model. Passive federation is not an option.
I am looking for the following flow:
The user triggers the login dialog, enters their username and
password then clicks "OK".
Behind-the-scenes, the application calls an active STS service in
our existing service application for authentication.
The service is actually a federated STS and passes the call through
to the (active) IP_STS which may or may not be ADFS.
When the IP returns the token to the FP, the FP modifies the token
with additional claims from the server data store before returning
the token to the client application.
The client application maintains the token in memory for
authorization checks (in Thread.CurrentPrincipal, for example).
The client also passes the token when making requests to other
service operations in our service application.
These service operations will use the token to
authenticate/authorize the request.
This is a very different use-case from any of the articles and samples I've been able to locate. Can anyone provide some guidance and/or point me in the right direction?
It is my understanding from Dominic Baier that WIF doesn't currently support the approach we are taking. We've taken his suggestion and created our own custom STS that moderates authentication using the Provider model.
Unfortunately, the farther we got into this, the more we realized that WIF isn't flexible enough to satisfy our needs at this point. We stuck with the custom STS approach but are using our own transport and credentialling rather than the WIF tooling. Hopefully a future release will give us what we want.
I am working with WCF Webhttp services. I have created a bunch of services and all that remains is to put in user authentication...
Questions
Keeping with the rest architecture style, should I authenticate each service call against the user db.
If so, I should just do authentication by supplying the credentials and password each time the service is called and make it secure with SSL. Basically, each webget/webinvoke function should contain the user credentials as parameters and I authenticate each call. Is this right? This seems rather inefficient.
Using session key somehow seems wrong but any pointers as to how to use Session in WCF Webhttp?
I am not working with ASP .net membership (will be looking into it soon) since I was working with Mysql and have my own registration/user database created. Should I be looking at that? Can I use a wcf authentication service along with wcf webhttp services?
Any literature on handling authentication in WCF webhttp services would be greatly helpful.
Many thanks
You can check Chapter 8 of RESTful .NET book (Amazon, Google books)
You will authenticate only the first call from the user, any subsequent calls will use the context of the authenticated user. There are several options how you can use SSL(TLS), like always or just when you send username/password.
I am not sure where exactly and how you store the authentication token (like in Session or similar type).
You don't need to use ASP.NET membership provider, in fact you may not use any membership provider at all, just use other authentication models. Usually, there will be only one authentication model per service, like you get the credentials, check them against persisted storage, if valid you set the security token and that token is used for all the next calls for a limited amount of time.
For an enterprise type WCF service, where potentially 10K's of thousands of clients will be authenticating and sending data to central servers, what is 'best' practice when it comes to sessions or authentication?
does WCF support a session, if yes, should I use it?
or should I simply pass username/password on a per call basis?
As blowdart mentioned, WCF Sessions are not the same as ASP.NET Sessions. You can read up on them here: http://msdn.microsoft.com/en-us/library/ms733040.aspx. Before you roll your own security, you'll want to get familiar with what WCF gives you out-of-the-box: http://msdn.microsoft.com/en-us/library/ms734736.aspx. They may get you close to your goal without writing a lot of code. Specifically, check out How to: Create a Secure Session. With secure sessions, the Client and Server cache credentials so you don't have to fully authenticate with each request. By default, you'll lose a secure session if the web server recycles. If you want a secure session that lasts through a recycle, you'll want to look at How to: Create a Stateful Security Context Token for a Secure Session.
WCF does support sessions yes; but they are not like ASP.NET sessions. Sessions are there to deliver messages in order (and other bits and bobs), they are not there to add shared storage between calls.
For authenticated service calls you should send your authentication details every time; security is applied on a per message basis.
If you host the service within IIS, you can still use the session that is from ASP.NET
by enabling aspnetcompatibility for the service behaviour.