I have a AngularJS/Web API/SQL Server application that currently uses token based authentication and authorization using the article outlined below:
JSON Web Token in ASP.NET Web API 2 using Owin
There has been a request to change this security mechanism to use Microsoft Identity. My initial research appears to suggest that JWT has more advantages as it can facilitate accessing multiple resource servers (single sign on scenario) and has a nice way of decoupling the different layers.
On the other hand, Identity is coupled with Entity framework (I use Dapper and do understand that I can write a custom provider) and it appears to be difficult to implement if your Web API is shared across multiple consumers (Web and Mobile app). But Microsoft recommends this framework for Authentication/Authorization. I ran into this article that helps implement it with AngularJS/Web API. Can someone help me understand if one is more favorable than the other and how? Thanks
Microsoft identity is not binded to entity framework you can write custom identity classes to use nhibernate & other O/R mappers
Related
Our application is currently written in .NET Framework + Razor, and traditional Membership authentication.
I am trying to modernize it, so I stawted to work on a .net core + react solution, but it has to cooperate with the existing application.
So currently, we have the old monolit, and an other .net core apis, called by react. The react is embedded inside the Razor.
Now I need to choose what authentication to use. I guess membership and other session based authentications can't be used, because there are multiple apps in multiple domains. So I need tokens.
I am not really sure about which solution can or should I use. I know buzzwords like bearer token, .NET Identity, OAuth + OpenId, but can I use any of them in this situation, to use it to protect the API and as well for the "traditional" razor app?
And where should I store the token? Should I store it in a session of the razor app, and pass it to the React too?
I need a solution where user credentials are stored in our own database, not something list Google's or Facebook's single sign on.
Is there a good tutorial for this?
You're asking for a lot here. I would suggest brushing up on this topic from the beginning. If you only know the buzz words you won't get anywhere quick. I can give some quick advice but if you aren't familiar with the basics this won't really help. There is no quick solution for your answer.
I would suggest authentication on the edge of the application to achieve a nice separation to work with the existing app. I would create a light weight method that receives the request from the client and gives the api gateway proof of the user identity in a way the API can verify. I would go with OAuth and OpenId Connect protocol to achieve this separation. Also, take a look at IdentityServer, it is an open source product that makes it easy to implement single sign-on and access control(Authentication) in web applications and HTTP APIs.
OpenId Connect to authenticate users
OAuth to limit collaboration for these light weight method calls
JSON Web Tokens (JWTs) for user identities
Now the problem with this solution is that there is a high level of trust between this light weight method call and the rest of the system. The principle of defense in depth would suggest to implement a layering strategy, so that if this layer is compromised another layer is there as the next line of defense. I'll leave the rest up to you.
Within our organization, our applications are registered as RP’s to our organizational ADFS server, which is v2. Traditionally, apps in the org have been built as single, monolithic apps using WS-Federation (passive authentication). Web API’s, also hosted within each app, are secured simply by the fact that the same FedAuth cookie is being sent over the wire when making the ajax calls from the app’s client-side code in the browser.
We are moving towards building a set of backend Web API’s, which we want to secure so that these are callable by any client, not just a web browser and not just by the hosting application itself. As such, we want to move towards using JWT tokens for these Web API’s. We've also started using ThinkTecture's IdentityServer (v2) to help in this regard.
We have just a few questions which I'm hoping the community can help provide us with some answers/pointers:
How should we configure IdentityServer and apps so that the apps use
the existing organizational ADFS login page?
How can we configure/integrate ThinkTecture IdentityServer v2 with
the organizational ADFS so that our API's can be secured using JWT
tokens but without forcing the user to provide their credentials
again (once they have a SAML token via WS-Federation)?
Are there any features in IdentityServer v3 which are compelling
enough to upgrade from IdentityServer v2 to v3?
1 & 2 - You might want to check out how to establish Relying Parties. Here's a whole article from BrockAllen (the genius behind IdentityServer) that walks you through the ADFS/IdentityServer2 integration.
http://brockallen.com/2013/04/14/getting-json-web-tokens-jwts-from-adfs-via-thinktecture-identityservers-adfs-integration/
3 - As far as I know, IdentityServer3 (IS3) was written to support newer authorization frameworks OpenID for the modern stack better than IS2 (which doesn't support OpenID). Either is fine for use. I personally started with IS3, mainly because of the support and documentation involved. It also integrates very well with OWIN/Katana, so it can self host reasonably well with no hiccups during implementation and deployment. One advantage IS2 has over IS3 is that IS2 has an admin UI you can use configure and register sites, IS3 doesn't. More info about this along with the thought process behind IS3 can be found here:
http://leastprivilege.com/2015/01/25/identityserver3-1-0-0/
We are building an application with following attributes:
Consists of a web app, a web API, and mobile apps in future
The web app will contain HTML pages (multiple features that behave
like single pages applications)
The web app will talk to the web API (communicates in JSON, using
JQuery AJAX Calls)
The web app + web API do not follow the standard MVC architecture
Need to support SSO (will be using client Identity Provider) and
forms authentication
mobile will be consuming the same web API
My question is around what approach we should follow for securing the application. Two of the approaches that we are contemplating on are:
Securing the web API only: the web app is purely HTML and all the
data (that needs security) will come from the web API
For this, we thought of using OAuth for securing the web API
Both, the web app and the mobile app will first perform
authentication, generate an access token (follow the OAuth flow)
Securing the web app using forms authentication/SSO, and using HMAC
authentication for authenticating the API consumer (web/mobile app)
This delegates the user authentication to the consumers (web and
mobile app)
The API consumers will use HMAC for authenticating themselves
How can we pass the authenticated user details to the web API? Don’t
want to pass it as a parameter in API calls
Or is there any other approach that is better than the ones we evaluated above? Has anyone handled a similar situation where an HTML web app uses a Web API, and authentication happens using SSO + Forms/custom authentication?
If you have any comments agreeing/disagreeing the two approaches, that would be welcome as well.
We understand that the web app cannot be purely HTML, and some of the SSO authentication part will have to be handled on the server side and that is ok. But the core application will be HTML + Web API.
Here is some additional information related to this:
- Using ASP.Net with Framework 4.0 (with VS2010 IDE)
- Using Web API 1, but open to switch to Web API 2
You may benefit from building an external authentication/authorization identity management component in your architecture. Your current use cases can probably be covered by the tools that come with ASP.NET, but the architecture will be hard to extend as you start adding different types of clients and SSO scenarios. Look at this and this articles for a more detailed explanation.
Azure ID and Access management offering can be a good option. If you don't want to use the cloud, there are some third party and open source identity servers available.
Here is a good free book to help you understand federated identity concepts in the context of Microsoft technologies.
Our current app is a standard spring 2.5 application with Form Based Authentication using Acegi. However, we need to expose some REST Service for 3rd party application and we are trying to use BASIC auth over SSL. We have used RESTEAsy for exposing the REST Services. Now, given that the rest of the application uses form & Session based authentication, how can I enable basic authentication for the few REST Services.
To me, the usecase seems normal, however, I couldn't find much reference on the web. Any comment/suggestions will be very much appreciated.
Regarding the more general question of whether to secure the REST service using Form authentication or Basic/Digest authentication - this is deeply tied into one of the more important constraints of RESTful architecture - statelessness.
With this in mind, logging into a service means keeping state on the server, which goes against the stateless server constraint. From an authentication POV, Form based authentication implies logging in, whereas Basic/Digest authentication means embedding the authentication credentials in each request, with no need to keep any state on the server. This is why this kind of authentication is much more inline with the way REST is meant to be build.
Hope this helps.
Check out Basic/Digest Authentication in the Spring Security Reference.
We have bunch of web applications which are secured using WIF and custom database authentication, currently we are in the process of building a RESTful public API. My question is whether we can use the existing WIF implementation to authenticate these new RESTFul service requesuts?
Thanks!
You can take a look at those two blog posts relating how to use WIF to secure an OData endpoint (which is REST on steroids):
http://blogs.msdn.com/b/astoriateam/archive/2011/01/20/oauth-2-0-and-odata-protecting-an-odata-service-using-oauth-2-0.aspx
http://blogs.msdn.com/b/astoriateam/archive/2011/01/21/connecting-to-an-oauth-2-0-protected-odata-service.aspx
I'll be in the process of integrating WIF with classic-REST and OData endpoints shortly, if you have any feedbacks, I'm interested.
Vincent-Philippe
REST services typically use different token formats from those supported by WIF out of the box (e.g. SWT vs SAML). You can extend WIF so it understands the appropriate token format. There are many examples that show how to do that.
See here for an example: http://zamd.net/2011/02/08/using-simple-web-token-swt-with-wif/