We have an application designed 3 years back in ASP.Net & SQL Server 2008.
We designed our own login DB design and forms authentication for the application with the help of ApplicationUser, Role, Then other transaction tables using UserId for getting the corresponding user records, history records.
So far no issues with new user registration and bringing and managing existing user records.
Now our client wants to integrate, Google Account Login for the new customer
and even the existing customer can sign in with the Google account.
We are wondering how it is possible. If you use Google Account to login, how we manage UserId mapping and other tables.
Is it possible to integrate the Google Account Login with the existing Application has designed with its own login implementation?
If yes, what are the things to be followed/considered for implementing this?
Another suggestion might be to use the nuget package SimpleAuthentication.**
Out of the box, it has an MVC controller which means all you need to do is implement the code for checking if the user exists in your system, etc. (ie. when you come back to your website from Google).
If you're on webforms (appologies) then you need to do a bit more work by creating your own form call back and then handling the return from Google.
** Disclosure: I'm one of the 2 main contributors for it.
I would use Windows Identity Foundation. It uses claims based authentication so all a user needs to access your site is a security token with a claim. You could set up a separate Security Token Service that authenticates users based on your own database and users could also retrieve tokens by logging in through Google or with any other party you configure your app to trust.
Ages ago I've created small ASP. NET MVC and if I remember correctly you can find the solution described here and here.
You may be able to find your answer in this Google+ document regarding adding Google+ authentication to existing Facebook implementations:
Adding Google+ to your Facebook Integration: Storing authorization
It talks about migrating from a single User table to a User and Identity table.
You could implement something like this in two ways:
Keep the username/password/email fields on the User table, and attach a Google authentication provider in the Identity table only when necessary.
Include username and password fields on the Identity table which are checked if the provider is "local".
You could use DotNetOpenAuth for that.
This is a "library that adds support for your site visitors to login with their OpenIDs by just dropping an ASP.NET control onto your page. It's that easy. An AJAX-style OpenID Selector control is also included for a slick, streamlined user experience."
This post explains how to work with it for Google account.
Related
I've got a user authenticated via IdS4, along with a few claims and a role, now I'm lost about what to with it. The general flow for the user is: Go to my site, log in redirects to IdS4 server. They enter their username/password, and redirect back to my site, along with cookies set.
I've not seen much beyond authentication in the tutorials I've found.
Should/How do I persist the user? Should I set up Identity on my MVC site? I'm just looking for a general idea, I think I can figure out the specifics, at this point my general Googling hasn't turned up much.
Thank you.
You can add ASP.Net Identity to manage users in your client MVC application , or directly use EF Core to store users in database without ASP.Net Identity .
But the problem is why you want to perisit or manage users in your client application ? You are using Identity Server to do authentication and IDS will connect the database/configration file to validate user and fill user claims , if you want to manage users/roles , you can add apis(CURD operations to user database) as protected resource , and your client app acquire access token to access that apis to perform user management . So that user management operations are share to clients which have permission to get api's access token . But if you want to manage specific users which only available to one client , you can mix asp.net identity and IDS4 authentication in client app .
I've been trying to wrap my head around the new ASP.NET Core Identity framework.
I want to be able to allow customers to sign-in using external providers so I do not have to worry about password storage. That works if I use the default provider: .AddDefaultIdentity<EntityUser>(), along with .AddAuthentication (with AddFacebook, AddGoogle, AddMicrosoftAccount).
Some people have a Google account and a Facebook account. I would like to allow users to login to their account, and then add additional providers to the same user (so long as the e-mails match).
The Identity Framework portion of AspNetCore seems to tightly control everything. I know how to override the views, but not how to override control-flow. How can I dip my own logic into its processes to coerce login, registration? I would also like to forward a user to the external providers when the user is already logged in.
All I need is a direction, they've separated concerns so much with the new AspNetCore that it's akin to an onion. This makes it difficult to know where what you want is. I don't even know what I don't know to get started.
It already works the way you want, users can add any providers you've configured from the page at ~/Identity/Account/Manage/ExternalLogins
You can see the source code of the ExternalLogins razor page has logic which will show options for the user to add social auth to their existing account.
I am implementing Authentication using Azure AD in C# MVC 5.0 application. I've created Azure AD B2C tenant , My tenant is having three application registered in it.
I would like to implement Single Sign-on so if user is logged in any one of one application he will be directly logged in other applications as well.
I tried to find solutions on the web but found no clear help on how I can start with it and implement.
Any help from the community would be appreciated. Thanks in Advance.
if user is logged in any one of one application he will be directly logged in other applications as well
Logging into one of applications doesn't make the user automatically logged in in other applications. This happens only after the user browses to the application and the SSO protocol takes control over the browser for the handshake sequence.
From the user perspective this doesn't make any difference. They navigate to any of your apps and they are logged in, they usually don't even notice the redirect/response sequence.
Think in terms of a ticket office in a movie theater (the SSO identity provider, Azure in your case) and multiple entrances to the theater (your applications). Buying a ticket (loggin in the identity provider) doesn't automatically make all ticket inspectors aware (you are not automatically logged in everywhere). Rather, when you approach particular entrance and you show your ticket, the particular ticket inspector accepts the ticket and you are allowed to enter (you log into one of applications and it accepts the token from the identity provider) without other inspectors noticing (other applications are not aware you just logged in somewhere).
As for the technical part, Azure implements both OAuth2 and WS-Fed protocols. You can find numerous tutorials on how to integrate a web app using either of the two. If you need assistance in specific technical issues, feel free to create new specific questions. Remember only to focus on specific issues, questions about possible recommendations (Should I rather use OAuth2 or WS-Fed? or Which specific client library should I use for OAuth2?) don't quite fit here and are likely to be closed.
If you have browser session cookies then you should be able to get SSO across all the app. You should also consider using Microsoft Authentication Library (MSAL) available at https://www.nuget.org/packages/Microsoft.Identity.Client. This library is still under preview.
I have an ASP.NET solution that acts as the primary customer portal for my customers. On this website the users can log-in access their important financial information and more. The website uses a custom authentication scheme that checks the user's username (their email) and their password (salt-hashed) against a Users table in a local database.
I am building a new MVC.NET solution that is more of a web-app tool to be used by these same customers for ordering. I want to re-use the sign-on mechanism of the ASP.NET portal to authenticate users. The goal is to save the user from remembering two log-ins or even having to supply the same log-in twice.
What are my options for allowing users who sign on to the ASP.NET solution to then be auto authenticated to the MVC.NET solution? I've listed some ideas below but are these "bad" or is there a more elegant solution? I'd love your input.
Common Cookie I could create a common cookie that the ASP.NET site creates and the MVC.NET site looks for. But is that secure enough?
Token in Query String I could create a token id on the ASP.NET site that is stored in the local database and is then passed in the query string of the link to the MVC.NET site which takes the token id and validates it against the same database.
Hybrid A bit of both?
Other? Got a better idea?
I've recently done something quite similar (the major difference being that it was internal to the company rather than for external customers) using OpenId.
The implementation of OpenId for .NET is called DotNetOpenAuth which should be suitable for your purposes.
It did take me a while to implement; but it works very well, is very flexible, and extremely secure.
More information about openid (from Wikipedia):
OpenID is an open standard that allows users to be authenticated by certain co-operating sites (known as Relying Parties or RP) using a third party service, eliminating the need for webmasters to provide their own ad hoc systems and allowing users to consolidate their digital identities.
Users may create accounts with their preferred OpenID identity providers, and then use those accounts as the basis for signing on to any website which accepts OpenID authentication. The OpenID standard provides a framework for the communication that must take place between the identity provider and the OpenID acceptor (the "relying party").2 An extension to the standard (the OpenID Attribute Exchange) facilitates the transfer of user attributes, such as name and gender, from the OpenID identity provider to the relying party (each relying party may request a different set of attributes, depending on its requirements).
The OpenID protocol does not rely on a central authority to authenticate a user's identity. Moreover, neither services nor the OpenID standard may mandate a specific means by which to authenticate users, allowing for approaches ranging from the common (such as passwords) to the novel (such as smart cards or biometrics).
Oh, and if you'd like further encouragement, Stack Exchange uses it!
#Jmrnet: in response to your last comment:
Perhaps I was unclear. OpenId in and of itself is simply for validating credentials from one location to another (more or less). It's entirely possible to implement as an SSO model where users do nothing different whatsoever - they don't have to choose a provider, or register, or anything like that. For example, in my setup, the user enters a username and password in a web portal, and then clicks a button to launch another site being automatically logged in by OpenId. Nothing different for the user at all! OpenId can be used with any initial authentication model you can think of (note the bolded section in the snippet from wikipedia).
Take a look at SAML:
http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
It works using XML and supports encryption.
I am currently implementing two SSO solutions for the same project.
In one, we are interfacing with an external partner and are using SAML.
In the other, we are allowing logged in users access to our Sharepoint and using the "Token in Query String" approach, since we trust Sharepoint to access our membership tables. This approach is much easier than dealing with SAML tokens.
There are many methods you can use, Mansfied described OpenID and RandomUs1r described SAML. Also, you can store relevant information in localStorage or in the session. I believe you should store relevant information with session.
It is not safe to put this in the query string, because if I register and log in, I will see something like UserID=1234 in the URL. If I change that to UserID=1235 and the ID is existent, then I can do some things in the name of the other user. This is called identity theft, which should be prevented by any means possible. So you should never have this kind of info in your URLs. Also, if you store the id of the user, you should obfuscate it somehow. For instance if you store the value in local storage and instead of 1234 you store encrypt(1234, salt), then the consistency of user action will be maintained.
I have four systems running on the same server. I want to let the users to log in once for all the systems. I made one user-management system to create users and edit them.
I tried to save in the session but it didn't help.
Any suggestions? I am working on asp.net.
There are two approaches.
Most resolve around the login happening at a central site, which then returns with an identity information field (login token) that the target site uses to retreive the user.
When you go to another site, the site redirects you shortly to the central site and if you are logged in (persistent cookie) you get back the identity of you.
Alternatively you can do a lot with referrers and playing around.
YOu want to do some research on the internet - what you loo kfo is "Single Sign On".
http://www.codeproject.com/Articles/27576/Single-Sign-on-in-ASP-NET-and-Other-Platforms
has some technical discussions.
Across complete separate websites (domains) you can read up on
http://aspalliance.com/1513_Cross_Site_Authentication_and_Data_Transfer
howw to do it - obviously shared cookies will not work there.
The best way to do this is with Federated Security. If you were using Windows Authentication then you could use Active Directory Federation Services (ADFS). In this model, users reference a Web application and the principal on the current thread is checked. If the value is null then information stored in the web.config will redirect the request to a login page automatically. This is assuming there is no a Windows security context, otherwise the user can be automatically logged in.
After the user is successfully logged into the environment, the principal on the thread is populated and a set of claims are issued that are specific for that user. Since the claims are associated with the principal and not with a specific application, they can be used across the board by any claims aware application.
If you aren't using Windows Authentication, you can still accomplish the same thing, the only problem is that you cannot use ADFS. Instead, you'll have to implement your own Identity Provider to replace ADFS. The .NET Framework does provide base classes and interfaces to help you accomplish that.
I would suggest looking into ActiveDirectory or any LDAP server for single signon to access all applications. If you cannot (or do not wish to) use LDAP, you could implement similar functionality (but with more development work/time spent) with any memory/disk store. If this is not possible, please share why as it might be useful to others.
Hope this helps.