Basically, I have 2 sets of projects, 1 contains the Web API Services and the other is the Web Portal which extracts data from the database through the API. However, following the set-up of ASP.Net Identity, the login process is all client-side. Is there any way where I can shift the Identity login to be performed through the API rather than having it directly connecting to my database?
I've tried installing Identity onto the API itself, but I'm also unclear how it is able to authenticate the user even if I pass the data to it.
Related
On IIS I have a login website which is used to get credentials from user and authenticate him. Authentication is done through:
FormsAuthentication.SetAuthCookie
Login application is written in asp.net webapplication.
Now there is another .NET CORE mvc web application which will sit as a child web application to this login website and needs to authenticate through login application.
By default child web application does not comes under login page.
How I can put this web application to use login from parent website?
HttpContext.User.Identity.IsAuthenticated in mvc core child application returns false and can't read logged in user.
You cannot. Traditional web-based auth and specifically FormsAuth utilizes cookies to persist the login state. Cookies are domain-bound, and auth cookies are also encrypted. You can only access the cookie in the first place if both apps are on the same domain, and even then, one can only read it if they can both encrypt and decrypt in the same way. The method of encryption has changed between ASP.NET and ASP.NET Core, so that's out of the window off the bat. ASP.NET used machine keys whereas ASP.NET Core utilizes the Data Protection API.
There's one minor exception, in an ASP.NET MVC 5 site, you can utilize the Data Protection API, through its support of OWIN. The two apps, then, can be made to encrypt/decrypt in the same way. However, by the very fact that you're using FormsAuth means that you cannot achieve this. FormsAuth can only use machine keys, so you'd have to migrate the legacy app to using ASP.NET Identity at the very least, first.
I have an application consisting of (simplified) 3 parts:
an Security-Token-Service (handling OAuth2 and OpendId-Connect) with its own seperated database (actually it's Identity Server 4 with ASP.NET Core Identity)
an API (with a seperated database)
and a SPA communicating with the API
Now the problem is that the database of the STS holds the user data and in the API-DB there is also a table user-accounts with the work-load-data for each user.
Currently I create the API-DB user-account on the first login of the user. Which works.
I am just wondering if there is a protocol (extension) defining a way to sync created/deleted users between an STS and other server applications.
Might be worth having a read of this and evaluating whether it fits your use-case:
https://en.wikipedia.org/wiki/System_for_Cross-domain_Identity_Management
Looking for a bit of advice regarding best practice regarding multiple user stores.
Currently I have Identity Server 3 set up using a factory method to connect to an Asp.Net Identity V2 user store.
I have two MVC Relying Party applications, both using OWIN to pass un-authenticated requests to the Identity Server.
Within Identity Server, both RP client applications are set up using Hybrid flow.
Now my question:
I want to have the Identity Server use mutiple user stores (in my case, we have users authenticating via our Identity V2 Store and also via ADFS)
I'm not sure how to detect or tell the which kind of user is connecting to the RP client application, and I'm not sure how to pass this information to Identity Server so that it can make a decision on which user store to use.
Any help greatly appreciated.
I have an ASP.NET MVC website in which I have added a "Web API 2 OData Controller with Actions, using Entity Framework".
This is the 1st set of code that is auto-generated.
I am calling this web API from a native client. I have added a reference to the Web API service through, Right Click, Add References.
This is the 2nd bit that is auto-generated.
I've configured Azure AD authentication at the client side. This is working.
What I want to do now is: setup authentication for each Web API call based on the user who logged in from the client. So the client's access token needs to be passed from the client to the Web API, and this token should be used to authenticate further.
Note that a lot of the code is auto-generated. So the additions to code should have minimal effect on regeneration of the code, if possible.
Later on the Web API will use the user information to filter data based on his identity, and use role based identity as well.
Any pointers on how to start with this? I feel that all the various pieces are available, but how to gather them into a single solution is just out of grasp.
The container that is part of the auto-generated solution is where we need to pass the token.
Here's the code:
autogenContainer.BuildingRequest += (sender, args) =>
{
args.Headers.Add("Authorization", "Bearer " + access token retrieved from Azure);
};
I am building a website using ASP.NET MVC 3 and have forms authetication setup correctly (user is able to register and login). I want to setup an OData WCF Data Services service so a Windows Phone 7 (Mango Beta 2 Refresh) client can authenticate and query the Odata service, with CRUD actions. This idea comes from the FullStack episodes here. They use OAuth login, but I wanted to use the user setup I already have, instead of an OAuth solution.
I do have this all working without auth currently (MVC app with Odata client on wp7), but am looking to make the Odata service secure. I guess I am looking for some articles or walkthroughs on how to get this working.
If forms authentication is not the correct choice, please let me know.
UPDATE
So lots of research done on this. There is an official how-to series on the blog for the WCF team here. Since forms auth is already configured on the web app, adding a check inside the QueryInterceptor provides the auth. However it uses a 'standard authentication endpoint' for client apps to actually 'login' that seems to use the base Membership providers, which I don't use. Is there a way to override this?
You could turn your custom forms authentication setup into a Claims based Federated Authentication Provider (STS) using Windows Identity Foundation. Then use that to authenticate your wp7 app with the STS provider and then send that claim (token) to your Odata service which will verify its an authentic claim. There is an example of this in the WIF training kit