I have a closed-registration site (set up as a resellers control panel).
There is no way to sign up externally as the admin creates the accounts and dishes them out to users.
I wanted to allow the user to attach their social accounts (fb/twitter/etc) to their logins after they have been created to make it easier for them to sign in to the website in the future.
The problem I'm seeing is that there doesn't appear to be a way to modify the third party providers to only allow login if the account already exists?
I've looked around the documentation and can't find anything eg,:
http://msdn.microsoft.com/en-us/library/microsoft.owin.security.twitter.twitterauthenticationoptions_properties(v=vs.113).aspx
So the question is - can you setup asp.net identity 2.0 so that external login providers can be used to login but are rejected if they aren't already registered to an account on the site?
I'm using the default MVC 5 template. I have a list of authorized users in a separate table from the Identity users table. When a user attempts to log in via Google, I check the user against that table in the AccountController's ExternalLoginCallback method prior to the SignInManager.ExternalSignInAsync() call. If they exist in the authorized users table, it continues the login process. If not, it redirects them back to the Login page. This of course requires knowing what their social login username or email address is in order to compare it, which in our case is not a problem because we are limiting login to specific users within our Google Apps domain.
Related
I have a website, call it "Site One" in which users create accounts with a username and password. For security, I then salt and hash the user's password and store it in a SQL Database. It all works great.
Now enter "Site Two" which is written by a different company. We would like to integrate the two apps so that if a user is logged into Site Two, they would be able to:
Create an account on Site one through a Web API.
Have a one click seamless login from Site Two back to Site One.
Is this achievable without Site Two being able to Store and Retrieve the password from the user account that they created? The only way I can think of this working is that after Site Two makes the WebAPI call to Site One to create an account, Site Two would have to be able to store the password which was used to create that account in the first place, thus opening a big security hole in case someone was able to get a hold of the password.
I supposed as an added security layer, I could prevent that password from being used except when the login info is posted from a known IP address, but I'm not sure if this is enough protection.
Consider implementing single sign-on (SSO) using SAML 2.0, where Site One is an Identity Provider (IdP) a Service Provider (SP), and Site Two is a Service Service Provider.
Assuming that users will visit Site Two first, then you would want to implement Service Provider initiated SSO on Site Two. The effect of this would be that whenever a user requests a secured resource on Site Two, the user would be directed to Site One, which would prompt them for the user for a username and password. Once authenticated, the user would be re-directed back to Site Two to access the secured resource that the user originally requested.
An overview taken from OASIS SAML 2.0 documentation:
The user attempts to access a resource on sp.example.com. The user does not have a valid logon session (i.e. security context) on this site. The SP saves the requested resource URL in local state information that can be saved across the web SSO exchange.
The SP sends an HTTP redirect response to the browser (HTTP status 302 or 303). The Location HTTP header contains the destination URI of the Sign-On Service at the identity provider.
The Single Sign-On Service determines whether the user has an existing logon security context at the identity provider that meets the default or requested authentication policy requirements. If not, the IdP interacts with the browser to challenge the user to provide valid credentials.
The user provides valid credentials and a local logon security context is created for the user at the IdP.
The IdP Single Sign-On Service builds a SAML assertion representing the user's logon security context. The Single Sign-On Service sends the HTML form back to the browser in the HTTP response.
The browser, due either to a user action or execution of an “auto-submit” script, issues an HTTP POST request to send the form to the SP's Assertion Consumer Service.
An access check is made to establish whether the user has the correct authorization to access the resource. If the access check passes, the resource is then returned to the browser.
one of our existing projects is running with a traditional authentication logic (having a user table in database). How the plan is to move the identity to AzureB2C with social IDPs integrated. But there are still some ares where we would need the reference of the existing user table. I need to find a way to map the logged in user from Azure B2C with the user table in database. I can read the email property from claims and try to map, but the challenge is user might have a different email for his social accounts. I know this actually defeats the purpose of the openId/oAuth to look back again in the user table after login. But this is a strange situation in running into. Any ideas how best this can be done ?
Copying response from: https://social.msdn.microsoft.com/Forums/en-US/221fce11-28ff-4236-a300-d6160ffc9379/azure-ad-b2c-how-to-map-the-user-logged-in-from-social-idp-to-a-local-user-table-?forum=WindowsAzureAD
Some facts are missing from your question so I will make assumptions which you can correct.
Assume that:
You do not use social IDPs today. So no existing connection between the social account and the local DB account.
This point is crucial because it is usually the user's prerogative (due to privacy) to make this link explicitly.
Assume that you will tell the user explicitly what you are doing as part of the transition.
To achieve this with b2c built-in policies you could:
1. Your app logs in the user the old fashioned way.(existing lookup DB)
2. Your app then invites users to register (in fact re-register) using a b2c signup policy which offers them social idp choices.
3. At the end of the b2c registration process, the user's email which was provided and proofed during the b2c signup and Object ID (newly created) is sent back to the App
4. The app uses the object ID and Graph to write the users existing id (old DB email or other unique user id you used today) to the new user's object in Azure AD B2C.
5. The app should note on the old DB that this user has been migrated so in the future the app does not present the option to re-register.
6. The app has to manage users in 2 different states.
Other alternative is to use custom policies and Account Linking
Here you could
1. Migrate all users into b2c using their old passwords. (assume you can get them from old DB in the clear) using Graph.
2. Point your app to b2c - users can login
3. Offer you users the option to link their b2c account to a social account. this requires custom policy and a policy path that is not public but its a simple sample we can provide.
I have a web app that is using an Azure AD to hold user accounts and allow authentication. The app has some internal users that are able to authenticate, but I also want to allow external users into the app (customers external to the company).
I am able to do this, but only by creating users that have "#mydomain.onmicrosoft.com" in the username. That is fine I guess.. but can I at configure the sign-on page somehow to not require the username to type this in??
Ex: if a username is "joe.bob#mydomain.onmicrosoft.com" I want them to be able to login with a username of "joe.bob" and that's it!
Full disclosure there is another question like this: Logging into Azure Active Directory without a Domain Name and I've posted a comment asking if anything has change since the question was active (2014). So if this is a duplicate question, then so be it, but I am wanting to know if there are any new developments (pun intended) regarding this.
Based on the description, you want to collaborate to work with external users. However you were create a account in the tenant directly. There are some difference between the Azure AD user and external user, more detail refer this link.
And AFAIK, Azure Active Directory still doesn't support to login with the username without domain name at present.
However the Azure AD B2C also provides the feature to work with external users and it allows Local Accounts login-in with (email address and password, or username and password).(refer here). You may consider to use Azure AD B2C if you want to login without the domain name.
And below link also helpful about to learn the difference between B2B collaboration and B2C:
Compare B2B collaboration and B2C in Azure Active Directory
In-addition, if you have any idea or feedback about Azure AD, you can submit them from here.
I've developed a feature on my web-site that allow to log-in using Azure.
So users in my web-site can sign-in using:
Azure (OAuth2). We're using a multi-tenant app. We're just using the application to log in users. So we don't really use the Access-Token to make requests. We just use the access-token to obtain the user email (decoding it with JWT).
Their own email-password they can set on my site.
This creates a problem:
Imagine an person that starts working in a company. The IT team give him an email that belongs to their azure account (with their account domain). This team also have an account on my site (configured with the same domains they use on Azure). So this user will try to log in my site using his credentials. We'll create his profile on their company account (due to the email domain). He sets his password. Sometimes he use Azure to log-in and sometimes he use his email-password to log-in.
The next month and, this person get fired. The IT team delete him from Azure. Although, the IT team forget about deleting him also on my site. So this user has permissions to sign-in with his email-password credentials and still be able to see private information (he can even delete private files).
I would like to know if there is a way to sync my app with every Directory that is using it. So I would be able to receive user action notifications (like user deletions). It would be great to receive a call to an endpoint with information about users important actions. This way we'll be able to delete the user also from our platform. So the company can forget about deleting an user on my site without having the stolen-information problem.
PS: I've seen you have a logout sync using SAML, but I wonder if we would be able to receive other kind of notifications, because we don't want to log-out the user when this logs-out from Azure.
If you have permission from the ex-user tenant administrator to access their directory, you can check if the user is listed or not by using Microsoft Graph API
I've been talking with microsoft support and there is no way of having microsoft calling our endpoint to receive some notifications.
So the only solution is ask for admin permission or, having the refresh_token from Oauth2, check the user still appears on Graph (https://graph.microsoft.com/v1.0/me).
I have an existing application that has standard user accounts, and we've just finished integrating Facebook login as an option. It works quite well, but if someone tries to login using Facebook for an email address that already exists as a user of the system, I'd like to associate them with the existing user account.
Before I go ahead and do that, though, is it safe to just do it, without requiring that the user login first? If Facebook says a user has a certain email address, how confident can I be that it's not fake?
I could, if required, set it so that the user needs to login to my app, then associate the Facebook account manually, but I'd prefer to keep it as simple as possible for them, without adding all kinds of steps.
Thoughts?
I think the best option would be having the user login into their account on your site before associating the Facebook account.
Assume a condition that a user on your site does not have a Facebook account associated with the email address they use to identify themselves on your site. A malicious user creates one using their email address, goes to your site to associate accounts, and takes over the original users account.
I believe Facebook does not require email address authentication to use the account.