I have an existing Web API project that currently has no authentication built in.
I want to add bearer-token based authentication, but I want to use a custom membership provider that I have used for other projects, although this has been with basic authentication.
There are some examples online that almost do what I need, but these have other technologies built-in that I don't want to use (e.g. Angular) or are not based on using a custom membership provider.
I could obviously do this using basic authentication, but I really don't want to.
How do I implement this?
Related
I am just wondering if anyone has some experience with this. I am trying out OpenIddict 4.0.0 to put together a real-life solution with the new Identity UI and razor pages approach. However when I register an external auth provider using the suggested unified OpenIddict.Client.WebIntegration package, I cannot see the providers on the default login page external section.
I also tried to use the openiddict-core sandbox aspnet.core server app but that as well does not show the configured GitHub external login option.
I could explicitly create links for the providers, however I do not see that as a convenient solution. The default code segment that calls SignInManager.GetExternalAuthenticationSchemesAsync() does not seem to collect the external providers registered using
options.UseWebProviders().UseGitHub() ...
What am I missing here? Thanks
It's a deliberate design choice, explained in this post comparing the aspnet-contrib providers with the OpenIddict providers:
The aspnet-contrib providers use an authentication scheme per
provider, which means you can do [Authorize(AuthenticationSchemes = "Facebook")] to trigger an authentication dance. In contrast, the
OpenIddict client uses a single authentication scheme and requires
setting the issuer as an AuthenticationProperties item if multiple
providers are registered.
For the same reason, the providers registered via the OpenIddict
client are not listed by Identity's
SignInManager.GetExternalAuthenticationSchemesAsync() and so don't
appear in the "external providers" list returned by the default
Identity UI. In practice, many users will prefer customizing this part
to be more user-friendly, for instance by using localized provider
names or logos, which is not something you can natively do with
SignInManager.GetExternalAuthenticationSchemesAsync() anyway.
I got absolutely confused when trying to understand the differences between MicrosoftAccount, AzureAD and OpenIDConnect authentications.
I am trying to build a .Net Core MVC app that allows some users to authenticate with local accounts, but some with Microsoft accounts. I do need to have a local user in DB for both types of authentications as I have some custom authorization mechanisms built on that.
I started with creating the app from template and selected "local accounts" authentication. Then I added the MicrosoftAccount authentication according to this tutorial (https://learn.microsoft.com/en-us/aspnet/core/security/authentication/social/microsoft-logins?view=aspnetcore-3.1). This is using Microsoft.AspNetCore.Authentication.MicrosoftAccount and seems to be working fine.
However, when I create a new app from template and select "work or school account" authentication I can see it uses a different library - Microsoft.AspNetCore.Authentication.AzureAD.UI. It seems to do the same thing. I can see there are events I could hook into to connect the AAD user with my local DB.
Looking through the web I found some other tutorials that were using OpenIDConnect for the same purpose.
How are those methods different? Which one should I use and why?
In future I would like to be able to query the user's directory for a list of other users. Would that requirement be easier met with either of those three methods?
MicrosoftAccount: This is the login with a general Microsoft account, using OAuth2. This is also what Microsoft will refer to as “private account” and useful when you want to authenticate someone just using their Microsoft login as an external authentication provider. This is similar to how you would sign in to sites with your Google account.
AzureAD: This is the sign in to a specific Azure tenant. This is often understood as a “work or school account” because it doesn’t sign people in using a public account but rather some account bound to some organization. Usually, you would have an Azure tenant where you have direct users (or configure it to allow external users) but you want to control access through that Azure AD.
OpenIdConnect: This is the general OpenID Connect protocol which you can use to sign in with many different authentication providers because it is a protocol that many of them will support. You can use OIDC to sign in to either of the above (and many other services) but that will require you to do some more configuration as you will need to figure out specific addresses for example.
You can always use the OpenIdConnect or the OAuth authentication scheme to authenticate with most authentication providers but those are the “manual” schemes which will require you to configure additional things. All the other authentication schemes, including MicrosoftAccount and AzureAD but also the other ones like Google or Twitter build on top of those protocols and come preconfigured so that you do not need to set up much else. So those are mostly for convenience and for more specialized support.
So when you want to authentication through Microsoft or Azure, then you should choose MicrosoftAccount or AzureAD. Which of those depends on where you want to authenticate with. If you have an Azure AD, then you should use that.
I am developing a REST based application using Web Api 2. On the project, I elected to use the individual user accounts option when I created my project. On the frontend, I am using a combination of angularjs and ios interfaces to interact with web api. I would like a user to enter their credentials and upon successful authentication, receive a jwt token(SSL) that they can use as long as the ticket hasn't expired. I read an article outlining how to create a custom storage provider, which I need as my user schema is different from asp.net identity.
What is the recommended approach to this scenario?
Can someone provide an example of how to setup .net individual accounts for authenticating users trying to access web api action methods? As stated above, the user interface is angularjs.
We have a client with following existing product line
Website1 (Uses form authentication using user information stored in SqlDB for website1)
WebSite2 (Uses form authentication using user information stored in SqlDB for website2)
WinApplication1 (uses Active Directory to authenticate user)
More products in line for future release.
They want to implement Single Sign on (SSO) for all their products with following features-
Product list that will be accessing by a user will be depended on his/her role.
It should be configurable. Roles are being defined in DB having Fk relation
with user table.
SSO service should be flexible to accommodate new product.
should use SAML to sucure token.
WinApplication1 has link for website1 and website2. If an user is login in WinApplication1
and click on any links of website1/website2, user should able to access the sites without
entering his credential.
If user is logned in in any product that user should be all to access any other product
he has access right without enterting userid/password.
We have following query
We are planning to implement SSO using WCF and WIF. Can all above requirement be fulfill
by using WIF.
We want to keep user authentication part in respective product as each product has their
own user store. OR WE SHOULD HAVE CENTRALIZED USER STORE?
What shouldl be the responsibility of STS (implemented in WCF) in respect to SSO &
security?
We have read lot about WIF from MSDN(http://msdn.microsoft.com/en-us/library/hh377151(VS.110).aspx, http://msdn.microsoft.com/en-us/security/aa570351.aspx) could not find any solid article/sample giving some practical scenarios. Most of them about using local STS…may be it is my bad luck.
I found a article that matches most of your requirements with practical implementation example.
The article describes an easy approach for programming against Windows Identity Foundation in a Single Sign-On (SS0) scenario from the angle of a relying party application. WIF supports a variety of Claims-based authentication scenarios but this document will focus upon using WIF to develop an application that supports SSO given the use of a SAML 2.0 token containing some basic claims.
Article also includes some part explaining about using roles in AD Users:
http://www.c-sharpcorner.com/UploadFile/scottlysle/windows-identity-foundation-and-single-sign-on-sso/
To impersonate the Original Caller in WCF Calling from a Web Application, you additionally need to follow:
http://msdn.microsoft.com/en-us/library/ff650591.aspx
Update:
difference between IP-STS and FP-STS and how to choose where to put STSes in your architecture. You will learn about federation, home realm discovery and how to leverage the WIF extensibility model in order to handle multiple identity providers.
http://bit.ly/bTo3w4
How a generic web site can be enhanced with identity provider capabilities regardless of the authentication technology it uses, simply by adding an STS page.
Another lab shows how to use an existing membership store for authenticating calls to a custom STS and sourcing claim values.
http://bit.ly/bQAQhA
WIF and WCF
http://bit.ly/8X63T5
Hope it helps.
I have a Web API project of ours that needs to be secured. I am planning to allow the user's that registered with my app to use the API [Forms Authentication], users with their own organizational accounts [ADFS] and Social Sign-In.
I have all the middleware available to plug-in and make available to the user's. However, in my application I do have custom roles and privileges that are to be provided so that my application authorizes the service calls based on the existing privileges. What is the best way to accomplish this.
I think that I will be required to provide my own custom implementation of the UserStore and UserManager with my own IUser Implementation.
Kindly suggest the best practice for this scenario.
With multiple authentication middleware registered, you can get multiple claimidentity's.
register each type of authentication you want to support.
I would be sure to add a claims transformation module at the end of the pipeline. Thinktecture has an example. ThinkTecture Owin Claims Transformer
This would give you one place to look up and add all the application type claims for an authenticated user in one spot.
Simple pseudo example (geared to webapi, but concept the same). Authenticate with bearer or basic or both then transform.
//identity 2.0 user manager stuff used in your modules
app.CreatePerOwinContext(ApplicationSession.Create);
app.CreatePerOwinContext<ApplicationUserManager>(ApplicationUserManager.Create);
// Token Authentication -> get a principle
app.UseOAuthBearerAuthentication(OAuthBearerOptions);
// Basic Authentication. -> get a principle
app.UseBasicAuthentication(app.CreateLogger<BasicAuthenticationMiddleware>(),
"Realm", ValidateUser);
// transform claims to application identity. Add additional claims if needed
app.UseClaimsTransformation(TransformClaims);
It sounds like you are looking for externalized authorization. Externalized authorization is the act of:
decoupling business logic from authorization logic
expressing authorization logic as centrally managed, centralized authorization policies
protecting your APIs through a common layer
enabling fine-grained & dynamic access control through the use of attribute-based access control (ABAC) which extends what's possible with RBAC (role-based access control).
Have a look at XACML, the eXtensible Access Control Markup Language. You can find some more information on OASIS's website.
Also check out NIST's project on ABAC.
Once you defined your authorization logic, you can decide how to enforce it. This can be done either via direct enforcement at the entry of your apps or can be done in a provisioning way whereby the permissions derived from the authorization policies are fed into an authentication token e.g. SAML as attribute assignments.
HTH
This is what I ended up designing for a system with similar requirements. The key is to separate the authentication and authorization logic.
Build Owin authentication middleware components that take care of establishing user identity based on various login methods you mentioned. Looks like you have this accomplished. Set ASP.NET identity based on the user.
Retrieve the roles/permissions for the logged in user from your store. This can be done as a separate Owin middleware or a part of your authentication. Add the permissions as Claims to your Principal.
Extend your roles/permissions store to map API service operations to the application permissions.
Implement a custom API Authorize attribute and apply it to every API operation. In this attribute you will have access to the operation name and the user Claims (permissions). Match the Claims with the permissions you mapped in the step above. If there is a match, return IsAuthorized=true, otherwise, return false.
Here is a similar issue at a simpler level.
How do you setup mixed authorizations for different authentications in .net (web api 2 + owin)