I have an ASP.NET Core 2.1 App using Identity to manage users. Now the requirement is to also support Windows Authentication. If a Windows user has an account in Identity an automatic login should take place. I think I need to generate an Identity cookie in this situations but don't know how.
You cannot use both Identity and Windows Auth at the same time. The best you can do is attempt to auth the user via an LDAP connection to your AD server. In short, the user would still need to explicitly sign in, but they could use their domain credentials to do so.
The situation is a little better if you implement IdentityServer. This is a bit more effort, but it can pay dividends in the future from having a centralized auth service (allowing you service APIs, mobile apps, etc.). IdentityServer can handle Windows Auth, but it treats it as an external sign in provider, like Google, Facebook, etc. You'd have a button or whatever to login via Windows, and then it would seamlessly authorize the user. See the IdentityServer docs for more information on that setup.
Related
Background
I have a web application "APP1" (front-end: Vue.js & Back end:Azure function) deployed in azure app service. I have implemented client directed sign in (easy auth using this), after that I can authenticate user using provider's sign in page [both AAD & google].
Target
I have another web application "APP2" deployed in on-primes server. I want to redirect to APP1 from "APP2" and automatically sign in without provider's sign in page. I will read credentials from environment variable.
Tried solutions
I have found a similar issue here, however I am unable to use the solution because the DB between AAP1 and AAP2 can't be shared
I have also checked the google identity providers documentation, however I am unable to find how to programmatically sign in without provider's sign in page
Question
Is it possible to programmatically sign in to google identity to get token without provider's sign in page
The whole point of google identity is to prove the identity of the person behind the machine.
OpenID Connect is an open standard that companies use to authenticate (signin) users. IdPs use this so that users can sign in to the IdP, and then access other websites and apps without having to log in or share their sign-in information. (id_token)
OAuth 2.0. This standard provides secure delegated access. This means an application created by a developer, can take actions or access resources from a server on behalf of the user, without them having to share their credentials (login and password). It does this by allowing the identity provider (IdP) to issue tokens to third-party applications with the user’s approval. (access_token, refresh_token)
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'm trying to setup an application to validate identity using Azure AD and acquire a token to allow access to a secure api. The front end application is written in angular and allows anonymous access. What can I use to access AAD authenticate and return an access token?
This will be an angular 6+ UI that is communicating to a secure .Net api using Azure AD for authentication. I have done a couple days research and everything points to a user logging in to authenticate using the login page. I need it to be by app and open the login page. I tried a couple examples where it utilized authentication/authorization and that didn't work because the app needs to authorization the user to talk to the api. I have seen where people were using Microsoft graph but once again it was user based and they were redirected to an azure login. I am looking for a solution that will allow me to setup an account in azure ad and authenticate the app on start to get an access token to allow communication to my secure api. If I have missed something somewhere in my research and test attempts let me know. This is my first Azure AD auth attempt and I feel like I am missing something for application authorization.
The problem is an Angular app is what we call a public client.
It cannot hold secrets and thus cannot prove its identity.
So, only user-based authentication flows should be used by public clients.
Confidential clients on the other hand can hold secrets as they run on servers that you control.
So for example, a back-end Web application or API would be a confidential client.
Those can use the client credentials flow to acquire access tokens and call APIs as themselves without a user being involved.
There is a bit of a fundamental issue in your question.
Your API requires authentication, but you want functionality to be available to anonymous users.
So you want to bypass authentication.
If you really want to bypass authentication for parts of the API, you could just make those endpoints available anonymously without a token.
So we are using IdentityServer4 for our web applications, all is good.
We have a new requirement from a client to allow them to perform SSO via their ADFS system using WsFederations, we already provide this for another one of our older web applications that is not tied into IdentityServer4 yet.
Ideally we would like to tie WsFedereration into IdentityServer4 so it is in one place.
Does anyone know if it possible to use IdentityServer4, so we redirect to IdentityServer4, identity that this particular client (possibly via an alternative URL), then IdentityServer4 authenticates against ADFS, collects the claims (probably basic, e.g. email/username/etc) , and we then supplement them with additional claims for access, and pass back to the web application.
What I'm trying to achieve ideally is to not change the existing Web Application, and to sort the plumbing at IdentityServer4, and the Web Application wouldn't know or care if this user was IdentityServer4 only or
IdentityServer4 + WsFederation. This would be useful for other clients across our applications to easily integrate in the future.
Alternatively I could deploy another version of the Web Application that authenticates directly with my clients ADFS system. However this seems a waste of server resources/maintenance for just one small client.
I had a look at the external options (where you click google on or near the IdentityServer4 Login Screen), is there a way to automatically redirect to the ADFS without event seeing the IdentityServer4 implemented Login screen.
Is this possible?
Thanks,
Jon
This was released 2017, see the example at
https://github.com/IdentityServer/IdentityServer4.WsFederation
OpenID authentication is inherently browser based. If I wanted to allow an OpenID user to authenticate against an API for use in alternative clients, is there an accepted best practice for that?
So if a user tried to log in with their OpenID into an iPhone app, for instance, how would that work? The only thing I can think of generating an API token of some sort for them and get the user to manually enter it somewhere. This approach is not user friendly.
This is the way sites like Basecamp work, but it still seems clunky to me.
The problem you're seeing is not unique to OpenID. Any password-less authentication scheme can have this problem. OAuth (http://oauth.net/) is a solution that is an open standard that is quickly gaining traction on a lot of web sites. It is totally independent of how the user authenticates, so their OpenID Provider does not need to support or even be aware that your site (the "service provider" in OAuth terms) is using OAuth. Your API client can be web based or even a local application!
The process would be something like this:
Roles:
the user: someone who has an account with your web site.
service provider: your web site, which has a programmatic API that requires some credential to access.
consumer: the client, whether web or local application, that needs access to the service provider's API.
Flow:
The user is at the consumer. He indicates he wants to access data at the service provider.
The user is either redirected (if the consumer is a web site) or a browser is popped up (if the consumer is a local app) and the user sees the service provider web site.
The user is either already logged into the Service Provider via a persistent cookie, or the user must first log into the Service Provider however that is done (OpenID in your case).
The Service Provider then asks the user: "Consumer (some consumer) wants access to your data (or our API, or whatever). Do you want to authorize this? (yes/no)
User confirms, and the browser window closes or is redirected back to the Consumer site.
Via some OAuth protocol magic, the consumer now has a secret credential that it can use to access your API and access whatever user-private information you just authorized.
Obviously I can't include the whole OAuth spec here, but you can see hopefully from the above that this should solve your problem. OAuth libraries exist to make adding support for it easy.
If you happen to be using ASP.NET, I suggest http://dotnetopenid.googlecode.com/ as it recently added OAuth support (v3.0 beta 1).
Neither OpenID nor OAuth define how a user authenticates. They define how the consumer directs the user agent to the authentication provider, how the user agent is directed back, and how the consumer can verify the identity that the user authenticated as.
The actual method used to authenticate is out of band for both schemes.
There are differences between OpenID and OAuth, but both require that the consumer use HTTP redirects and callback URLs. They're both browser based. If your app speaks HTTP, it can do either. However, a main point is that the user is only entering credentials into a trusted app.
What you want is not possible with OpenID. OpenID is based on the premise that you (the iPhone app) only want to know about your users that their OpenID-provider trusts them. They never authenticate themselves to you.
Good OpenID-providers in fact even prevent that you mediate the authentication process (as this would expose users to a possible attack - by you!): they demand that users login with them directly and refuse login-by-referral.
See: this related question
The problem is that the openid spec has no standard provision for authentication with the provider, so the provider can elect that authentication happens via a phone call or whatever.
Hopefully more providers embrace OAuth. Alternatively you could hand code the authentication for a few of the bigger sites.