I've REST services (Web API) and admin panel (MVC) in one project on ASP.NET Core 2.1. I want to secure my API with JWT token, and my MVC pages with cookies. Can I combinate these two authentication ways. How to configure my Startup.cs, Authorize attribute and sign in functionality.
I suppose you should use an OAuth 2.0 framework. please check IdentityServer4 it enables many features in your applications.
IdentityServer is middleware that adds the spec compliant OpenID
Connect and OAuth 2.0 endpoints to an arbitrary ASP.NET Core
application.
Typically, you build (or re-use) an application that contains a login
and logout page (and maybe consent - depending on your needs), and the
IdentityServer middleware adds the necessary protocol heads to it, so
that client applications can talk to it using those standard
protocols.
Related
I have an ASP.NET Core 2.2 website. It's a portal. Some pages are served by ASP MVC Views, other pages redirect to Angular SPAs.
Some views of the ASP.NET site and some Angular apps need to be behind username/password.
For Angular SPAs it makes sense to use JWT authentication. There is a login component that makes and API call, gets back a JWT token and stores it in the local storage. This works because the JwtBearer scheme was used in ASP.NET for authentication. But once I authenticated with JWT, how do I make plain (not-SPA) ASP.NET Views/Routes respect that JWT token?
Is there a way to force browsers to automatically append the Authorization header based on a Jwt token?
Is that possible to use cookie-based authentication in .NET along side of Jwt authentication?
Is there another way?
Thanks.
How to add custom claims for an application group of type "Web browser accessing a web application - Client-Server application" in the provided token?
I'm building a web app using an Angular client and .NET Core Backend. I've managed to authenticate the client, but i can't use explicit authorization roles for controllers since the token doesn't provide those roles, e.g.
[Authorize(Roles="Admin")]
Yes - you have to augment the id_token as per this.
But in order to do the "Roles=Admin", you have to have a claims rule that sends the groups as a claim type of "Role".
I am new to Identitysever3 but I have worked with OAuth and OpenId.
I need to create a MVC client that will interact with QBO (Quickbooks Online). QBO uses OAuth by it's own.To start with I followed the github sample project from QBO community to use QBO REST API. This MVC app has OAuth stuff in MVC controller.
Now I need to create actual MVC project that will interact with QBO. I am after best practices to authorize my project. Here my authorize server would be QBO. So is my app is the right candidate to use Identityserver3?
My understanding is that I need to add Identityserver 3 project in my solution and use authorize server URI, client Id and client secret provided by QBO.
I assume Identityserver 3 is a framework that is the best way to use OAuth and OpenID connect as a separate project so it can be reused in other solutions. AND it's not an Authorization server, am I correct?
waiting for help please.
I assume Identityserver 3 is a framework that is the best way to use OAuth and OpenID connect as a separate project so it can be reused in other solutions. AND it's not an Authorization server.
This statement is not correct. In fact IdentityServer3 implements OAuth2 and OpenIdConnect and is an authorization server. If you have QBO as authorization server, you don't need to use identityserver3.
what you need is a client for OAuth2 and OpenIdConnect. You can use IdentityModel which is implemented by the same team that implements IdentityServer3.
A new application is being built with an Angular Client and a ASP.Net Web API back end. The back end will be consumed by the Angular Client only in the short term (1 year), but will be consumed externally (mobile and 3rd parties) in the long run.
What are the pros and cons of using ASP.NET Identity vs IdentityServer4 initially in securing the API? How difficult will it be to switch over to IdentityServer from ASP.NET Identity down the road and is it worth the effort of using IdentityServer from the beginning.
ASP.NET Identity is a user store, with some helper libraries that enable cookie authentication on top of it. Using ASP.NET Identity to protect HTTP APIs is not what it was designed for.
IdentityServer 4 is an OAuth & OpenID Connect authorization server. Using IdentityServer to protect HTTP APIs is exactly what it was designed for.
I've been assigned to find a way of implementing SSO in our products. We have several Winform applications and one asp.net 4.0 web app (not MVC).
All the products are built using .Net 4.0, the web app is ASP.NET 4.0.
Some of the Winforms are commmunicating with our API via web services (asmx) and some uses our API directly. The web app is using the same API as well. We offer a set of web services (asmx) that uses the same API to external clients.
Currently we have our own authentication implementation (user, password, roles) in our systems and we would like to replace that with SSO. Or can these two authentication regimes co-exist somehow? The Winforms are used in intranets and the web app is used both in intranets and we also hosts the web apps for clients (accesible from the Internet).
The users are created in our system, but at the same time we import users from Active Directory using our own tool. Active Directory is really the primary user source.
I have read about Windows Identity Foundation and I wonder if I can use that to implement SSO. But what I don't understand is how to use WIF in the winform applications when they use the API directly.
What I would like to achieve is to remove all user administration from our system and use Active Directory as the user source. I guess that means using ADFS 2.0 to create claims, etc.
I can use .Net Framework 4.5 in this implementation (I know that WIF is now a first class citizen in .Net Framework 4.5).
Do you have any advices how to do this? Is WIF the best alternative to achieve SSO across winforms applications and web apps?
There is a way to get the WIF authentication cookie from within the WinForms application.
To do it, you just host the WebBrowser control and point it to the login page of your web application. Assuming the web application is federated with the ADFS2, the web browser control will automatically follow the flow - it will redirect to ADFS and stop there to show the prompt for user credentials (ADFS2 in Forms Authentication mode) or just authenticate using NTLM/Kerberos (ADFS2 in Windows authentication mode). Then the web browser will redirect back to your application.
This is where you hook your code. You just add a handler to the web browser's navigation event and you check when it comes back to your application AFTER ADFS2.0 authenticates the user. You can then call the InternetGetCookie method in the WinForms app to get all the authentication cookies issued by your application and you can close the window which hosts the web browser.
At this point, you have all authentication cookies issued by WIF (the SessionAuthenticationModule) for your application. You can now call your application web services and inject cookies into http calls. The web server will correctly recognize users as authenticated which means that all you have to do is to add proper authorization to your web services (the PrincipalPermission on your web methods should do).
An alternative approach would be to expose WCF services from your web application and guard them with WS-Federation active authentication. The downside of this approach is (in my opinion) that if your identity provider (ADFS) is further federated with yet another identity provider which DOES NOT necessarily implement WS-Trust/WS-Federation then the active authentication will probably fail (because the other identity provider does not implement it) while the passive scenario will still work (a bunch of redirects will sooner ot later end with a page which requires user to provide the credentials but the flow of authentication protocols between consecutive identity providers does not matter).