I'm testing out ServiceStack to see how much faster the development is with this product rather than with Asp.Net Core's Web API or similar products.
I have successfully set up Service Stack with my own configuration of IdentityServer4 and everything runs fine.
My confusion is whether working with IdentityServer4 means I am required to now maintain a Web Api project along with ServiceStack? What's the reason the API is there?
I can see that I can make direct calls to the endpoints (requiring Authentication, roles, etc.) and that works in conjunction with IdentityServer4.
Would love some insight on why the Web Api project is needed and whether I can just completely get rid of it, as I was under the impression ServiceStack was a replacement for WCF/Web Api?
ServiceStack's mvcidentityserver project template that's used in the documentation of ServiceStack's integration with IdentityServer4 was an enhanced version of Identity Server's "OpenID Connect Hybrid Flow Authentication and API Access Tokens" example project that used to be maintained at https://github.com/IdentityServer/IdentityServer4.Samples/
The project template contains Auth integration examples with ServiceStack, MVC & Web API. The Web API examples were inherited from the existing IdentityServer's example project, which is optional and can be completely removed.
Related
I couldn't find answers about using both frameworks working together.
We are planning to build an identity provider service (like Google Account) which is used to authenticate a user and provide OpenId Connection protocol to a Rely Party app. We have existing projects built in ServiceStack which work all fine. However, ServiceStack seems not to be compatible with IdentityServer4 in regards to authenticating a user. ServiceStack has its own authentication mechanism and IdentityServer4 relies on Asp.NET Identity Model. If I sign in via ASP.NET Identity Model, ServiceStack APIs may not recognize the user has signed in. And vice versa.
Is there any suggestion about this is a dead end or some solution that may make them work together?
The mvcidentityserver Project Template contains a pre-configured ServiceStack + IdentityServer4 starting project template:
$ dotnet tool install -g x
$ x new mvcidentityserver ProjectName
See the Using IdentityServer4 Auth in ServiceStack docs for more info on ServiceStack + IdentityServer4 integration.
In addition there are a couple of options available from the ServiceStack community:
Using IdentityServer 4 with ServiceStack and Angular
servicestack-authentication-identityserver
JwtAuthProviderReaderPatchedForIdentityServer4.cs - description
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
I am having two projects under one solution. one is for UI which is MVC and another one is WEB API service. I want to make the WEB API service to be authenticated as well as authorized during the call from the UI project inside the WEB API project.
Please share your stuffs on the above item, as i am so much confused on having the solution from the existing links.
I'm a big fan of Auth0 for authentication. I use it extensively in similar architectures as you described e.g. separate UI project with separate back end API project. In my case I use Angular for the front end, and ASP.NET Web API for the back end with Auth0 sort of being the glue that holds the security together.
Their docs are very good with lots of downloadable samples for most of the common stacks.
Basically, the front end talks to Auth0 platform and gets a token. This token is then used in any authenticated calls to the web api, therefore decoupling the security and the main functionality of the app.
And it's free for a lot of use cases! Win win!
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.