I'm making a project and here's my solution organization:
Core - Entities, Interface's etc..
Data - Repositories, Context's
Services - Bussiness logic
Api - Restful api
Web - Presentation
Now I want to make registration in my Web project. Data (email, password, etc) will be sent to my Api. Also Web project will get all data from my Api. I want to ask where I should make Api access logic? In Web project controllers, Data project or make class in my Web project to access Api? Maybe you'll guys suggest some approach?
Web project is ASP.NET MVC and Api project is ASP.NET MVC Web Api project. I'll call user will input data (username, password) i'll pass that data to Api project and it will do the work. I want to make that user could register to API using GUI. User will input email, password etc and the he'll get access token from API.
Related
I'm working on a project created using Identity Server 4 for authentication, an API application that handles all the data and business logic and a client web app.
The IdentityServer project uses a different database for managing the users of the app and the API project has a copy of that table that gets synced with the one from IS when the user logs in.
The problem I'm facing is this:
When a user confirms his email the information is handled by IS but until his first login, the user appears to have his email unconfirmed in the API project.
How can I solve this without coupling the IS project to the API one?
I see various way to handle this.
Use messaging system to sync data (Users and it't update) between both the database.
Access DBContext of API project into the IS to manage users.
Or even simply have api to give updates to API project upon first login.
I am building an scalable application. Scalable for me means that back-end (ASP.NET Core 3.1) and front-end (React) are separated. I am thinking about using Kubernetes to do that.
Let's say for instance that back-end has an authentication and authorization based on ASP.Net Core Identity using JWT, so user can be registered and all registered users' data is saved in database. Registration functionality is provided via back-end's API endpoint /api/register.
[HttpPost]
[Route("register")]
public async Task<IActionResult> Register([FromBody]User user)
Let's say I have each general functionality provided as an API endpoint - then I want to access these endpoints in my front-end application, but, I want to be sure that only my front-end application will access these API endpoints, so only my client app can access these endpoints. In the future I want to write mobile app accessing these endpoints also, so I want to allow only "authorized" client apps to access my API. So, if someone write his own client-side application and call my API it won't be possible.
Here comes the question: what is the best and professional way to do that? I know, that in appsettings.json file AllowedHosts can be defined, but is it the best way and if so, how to do that safely? Is there any need to do that?
Maybe the question is not correct, but I think the problem has been described
in an understandable way.
Thanks for your time in advance.
I want to create an ASP.NET MVC application that will authenticate to an Azure tenant and get the information about the underlying tenant info such as subscription ID etc. -
This similar thing has been done by another application here - https://overcast.sharegate.com/login
Let me know any article or related info for this requirement.
As Nick said, you could use Tenants Rest Api to get the tenants for your account.
Use Azure ad Implicit grant flow to get your access token with your username. And send the request to Tenants with access token as http header. Then you will get all the tenants for your account and the detailed message like tenantId, tenantName.
If you just want the Azure Subscription details, you can use the following:
Subscriptions - Get REST API
Microsoft.Azure.Management.ResourceManager NuGet package. The Azure SDK for .NET consists of the Microsoft.Azure.Management.ResourceManager Namespace and the ISubscriptionClient Interface that would let you get information about your subscriptions and tenants.
However, if you're looking to access information across the Microsoft Cloud services and build unified but unique user experiences, check out the following resources about Microsoft Graph:
Building ASP.NET MVC apps with Microsoft Graph
Module: Build ASP.NET MVC web applications with the Microsoft Graph .NET SDK
For implementing the sign-in experience to Microsoft through an ASP.NET MVC solution, take a look at this document.
I'm developing a Blazor (ASP.NET Core hosted) project and hosted on IIS.
Back the day when I use ASP.NET core 2.2 with razor page, it can use windows authentication.
However with dotnet core 3.0, only Blazor server-side project template has windows authentication option to choose.
But what about the Blazor (ASP.NET Core hosted) project template? From my understanding, it's just like Blazor client-side + dotnet core MVC backend.
I don't understand why there's no "windows authentication" option for it.
In Blazor WebAssembly apps, user authentication and authorization must be handled by the back end web Api, because all client-side code can be modified by users.
Your ASP.NET Core Api can use the Windows authentication and keep track of the authentication state in a cookie. In Blazor WebAssembly you can implement an AuthenticationStateProvider which calls your web Api to get details about the authentication state of the user.
Then you can use the AuthorizeView component to show or hide content depending on the users log on state.
A clear description you can find in Blazor Prepare for Authorization
Source code example in https://github.com/Forestbrook/BlazorAuthorizationExample.
There are 2 problems to solve.
For the webassembly, use the solution with the AuthenticationStateProvider to get the user authenticated and do a call to the api (enable windows authentication and disable anonymous login) that returns the windows username and the authorization roles, if you use them for authorization. Load the roles into client side identity as claims and the webassembly is set up for authentication & authorization.
Because all code is run in the webassembly, you should also protect the serverside api controller actions with authorization attributes, except for the call that identifies the user to the wasm.
Enable authentication and authorization on the server api and use the IClaimsTransformation to modify claims for the authenticated user.
When configured correctly, you can use authorization attributes on the controllers too, securing the api.
You can implement StateContainers on both sides to cache user information so you don't have to read the database for the same info on every action. I use a singleton for that, with a retention time of 5 minutes. You may then update the timestamp on every cache read so you effectively call the database only once.
I think it will including this feature in later version according to asp.net core github
This is a multistep process, the basic outline is as follows. Best guide I have found is from Chrissanity.
On the server get the current Windows User and store it in a cookie using Blazored.LocalStorage nuget package.
Read that cookie in on the client in ApiAuthenticationStateProvider.cs
In a .razor file use [CascadingParameter] private Task<AuthenticationState>
authenticationStateTask { get; set; } to read the value into your component.
We are working on an management application that is build using a mix of older and newer technologies and frameworks. The generic architecture looks like:
Architecture Overview
It started out as an ASP.NET WebForms app, but when a mobile client was requested, we had to provide the data through an API (WebApi). Now we have .aspx pages running along Angular pages (that call the API).
We are managing our users in a custom way - they are added by an admin and saved in an SQL DB (there is no registration page) and security is assured by a plain security cookie (encrypted user info) that is set after login and provided with each call (by: .aspx pages, Angular pages, mobile app).
Now we thought about stepping up our security (authentication and authorization) and user management by using OAuth 2 and Open ID Connect offered by an Identity Provider. Providers like Auth0 or Okta do not offer support for WebForms (documentation is scarce) and we don't know if it's worth implementing OAuth + OIDC by ourselves.
What would be the right approach for improving security, in the given scenario ?