ASP.NET newbie question. I'm starting with ASP.NET's Starter Site that comes with a set of built-in registration, authentication pages, and membership DB.
Now my question is, how can I restrict registration to my site? This site is for a patient practice and only patients need access.
I have read about roles, but assigning roles means the user has already registered. I don't want users created in the DB without being authorized either by email or other credentials that an admin will enter prior to registration.
Please let me know the best way to achieve this modification to the starter site template.
Thanks in advance.
As siva.k mentioned in a comment you can remove the registration process from public access, that means users will not be able to register by themselves, an administrator must be in charge of creating users. This implies that you will need user security roles...at least if you don't want your patients to have access to administrative areas such as user management.
Another approach which will require a bit of more effort is to "send email invitations to your patients". Someone perhaps an administrator simply need to enter (at least) an email address and the system would trigger an email inviting the user to register. Obviously, this will require to have a registration page/view to be publicly accessible, but protected to only users who have been sent out an invitation. Determining whether the user is genuine or not it's quite simple. At the time the system sends out the invitation, it logs an entry in a database record...say an email address, a random unique code and perhaps an expiry date to validate the invitation. The random unique code could be whatever you want but must be unique within the system and most importantly NON-SEQUENTIAL (as in incremental integers or something like that). This code can be sent to the invited patient in the form of a url query string parameter, this url is the link to the registration page. Then, the registration page will extract this code from the url, validate it against the database record, deletes the record and then serves the registration page. If the validation fails you can easily respond with a 403 or 404 http code.
As I said, it requires a bit of effort on your side but you could make it a robust solution you can report on.
Related
I've created an ASP.net web page that allows the user to create an account. This site is purely for my own practice with the environment, but I have a question about the best way to handle logging in.
My site is more or less (eventually) going to be similar to Twitter.
When the user signs up for the site, they are required to put in a company ID number and a handle. In addition, they have an option of adding an email address, if so desired.
On my login page, I want the user to be able to login with any of those three options (email address, company ID, or handle).
The confusion that I'm running into: what if someone makes a handle that is the same as someone else's ID? How do I handle that?
Would the best option be to validate based off of the (salted and hashed) password if it matches more than one? I would guess no, but I'm not sure.
Now, I know that there are a lot of different options to alleviate this problem (require at least one letter in the user handle being the primary one that comes to mind, or as someone commented, adding a constraint to deny the creation if the ID already exists), but since this is just a mental exercise for me I figure I should learn something about it.
Let users specify the type of credentials they are providing.
Create a separate login form for each type of credentials: company ID, handle, e-mail address. When a user visits the site, you ask them to select the type of credentials they are providing. You could even remember this preference in the browser's storage.
When the form is posted, you know exactly what to validate. You don't have to worry about a handle being the same as a company ID. Store company ID, handle, and e-mail address as separate fields in the database with each user's account.
This is similar to sites which use federated authentication and give user's the option to sign in with Google or Facebook.
I've created a asp.net mvc4 web site. I've implemented Form authentication also.
In this web site i want to block access to my web site client in a same time (if a client of my website is already open his or her account in a computer then that client can not get any permission to open that same website on the same time in other computer or any other browser of the same system).
I want to provide one paid service to user, and I don't want him to just share his username and password with many people to use my service simultaneously without paying for it. please help me soon
How can I implement this. do i need to maintain some login information in database or is there any built in tool available for this.
To my knowledge there is nothing built in, but you may be able to implement your own version of the ASP.NET authorization providers.
Upon successful login you would need to store the value of the FormsAuthenticationTicket in your database and associate it to your user record.
On every page load you would need to check the value of the ticket against the database record for that user. In case of mismatch the user would be logged out.
Using this approach if User A and User B were using the same credentials, User A was logged in and if User B then logged in, it would invalidate User A's session and they would not be able to view content at the same time. You could also log the activity when a session is overridden, along with IP address and User Agent to help you identify users that are sharing account details.
This feature is not built in.
I would add an "IsLoggedIn" bit column to my "User" table. Then you could check this column to see if the user should be allowed in.
The problem is going to be knowing when that flag should be set to false. It's easy enough to set the flag to false if the user clicks "logout" or in the "on session end" event, but I think you'll run in to cases where that's not good enough. For example, if a user logs in from a laptop and the laptop's battery fails, you aren't going to get any notification from the client that the user has left...
I think David has already given most of the idea (+1) , However for problems like closing browser without logging out, You can handle it in window.unload() event for setting the flag in your table .
I am implementing the Facebook Login widget inside my ASP.NET 4.5 C# web application. When I clicked the login button I eventually get the accessToken. My question is regarding making the user persistant in my application.
There is data that is associated with the specific facebook user. when the user log off and log in back (assuming that the cookie might be deleted), I want to be able to recognize him again to display the relevant information.
I know that I need to use the database, but what is the best practice to do so. Should I use the user ID or email address as a unique user identification string?
I am using MySQL as the backend.
I have been working on a similar application which uses either Facebook (OAuth), Google (OpenId) or a manual registration login approach.
My prefered solution was to ask the user for their email address, you will need to request extended permissions on the email field from Facebook as it is not offered up by default.
http://developers.facebook.com/docs/authentication/permissions
My table structure looks like this.
User
Id (int)
Email (nvarchar(256))
FacebookToken (nvarchar(256))
GoogleToken (nvarchar(256))
The advantage to this method is you are able to link up your users to the right account if you decide later to add another authentication / identification service or roll your own. It won;t matter if they login to FB, Google or Twitter - you always know whcih account to attach them to.
It is also useful to have an email address for each of your users regardless.
Regards
Steve
As we knew in Web got a lot of tutorial for Azure ACS, but most of it stop at inset simple ACS into website or application. Now, i wondering is that possible to identify and link up all the famous user oauth provider, and add them a new user in database then assign role to them ? After the process, they just simply click any provider then will bring them back to the same account ? Do you having such tutorial can share? Here is the process flow i want to make:
Window live + google + Yahoo + Facebook, one person may having all four account, but then i need their info also, then i create my cuatom data entering page and the problem is how can i link up ? How can withdraw the unique id to identify ? So i can recognize it..and assign role to it..
Question 1: how to link up ?
Question 2: how to identify in system?
Question 3: how to give role ? Not giving from azure admin page but through the code
Thx
There is one thing you should be aware of, when working with ACS (and with Claims in general) - you shall get to know the Claims.
Now, to the ACS specific question. Windows Azure Access Control service is not the magic wand that will do what you desire automatically. ACS is the easiest way to get working with Claims, and to work with only one set of specific claims, and don't bother with all different implementations of different protocols. In fact, what you work with, when creating browser based application, is WS-Federation protocol (and SAML token by default, but you can also use SWT token), and not OAuth protocol. The user uniqueness you get, when someone logs-in with your site, when using ACS is the strict combination of following two factors:
User identity
ACS namespace
The uniqueness you get is NameIdentifier claim (represented by: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier).
The first catch is that, say I am "john.doe#gmail.com" identified to your site through http://yourcompany.accesscontrol.windows.net you will get nameidentifier "X". When, I, the same "john.doe#gmail.com" identify myself to your site, through http://yourcompany-live.accesscontrol.windows.net/, you get nameidentifier "Y"! And this is true for all identity providers, which you link via your Access Control Service.
The second catch is: Live ID identity provider, when configured via ACS, will only give you a NameIdentifier claim. And nothing more.
Now to the questions:
Question 1: how to link up ?
The only feasible way to link up identities, is to built your own linking logic in your application. What I would do, is to stop using all the auto generated code and passive redirection to ACS, but to handle some of the Passive Federation manually. This would mean - I will watch out whether the user is logged-in or no. If not logged in, I will redirect the user to my own custom login page, where I will get from ACS the configured login options. When the user is logged-in, I will create an entry in my own user data base for that user. I will have fields (or linked table) for all possible identity providers that I would like to link up to a single user. Understand, I will store all the NameIdentifiers the user may have. Now, how will I link a user account. There may be different approaches. First, you must indentify the user to allow him/her to link an account. Then create let's say a "linkage ticket" with some unique ID (not GUID, to be easily remembered by the user). Show this ID to the user, and offer him an option to login with another provider (retrieve the list of privers from ACS). When user comes with another provider - show the field when one could enter the ticket. Check the ticket, and if it is valid - link to the existing account.
Question 2: how to identify in system?
As mentioned in answe one - you will need to have your own custom user database, where you will have one account per user, but that account will hold all the NameIdentifier claims, issued by the different authorities. Thus you will be able to uniquely identify the users with linked accoutns.
Question 3: how to give role ? Not giving from azure admin page but
through the code
In your architecture it will be very hard to maintain the roles in the ACS, because of the complexity you enter when requiring to link multiple accounts. I suggest that you keep user-role assignment withing the application database. The part that you have local user accounts, you will assign role(s) to each account.
Note, when I say local user account, I don't mean to support local login credentials, but just user profiles!
I'm trying to put together a (real-life) game for my college campus and it'd be really easy if they just go to a website and click a button that says "Sign Me Up!" in which that button would send the username that person is signed in as (Since user names on our school laptops are always firstname.lastname). If there's no way I can grab the person's username, is there a way I can prevent people from submitting multiple forms with more then just a cookie?
are you looking this...
HttpContext.Current.User.Identity.Name
Are you going to be able to host this site on your College's network? if you are, and you've enabled Windows Authentication rather than Forms Authentication then querying the Current user's Identity will "just work".
If you're going to have to host the site elsewhere, or on a different area of the college network (say a different domain), then using windows authentication won't provide the solution for you.
You'll need to create a simple registration page (you could easily use the standard registration wizard and login controls, talking to the default ASP.NET Membership database - see Introduction to Membership for more details).
In terms of limiting sign-ups to one per user, if you collect (say) a college or similar email address you can check those for uniqueness as well, and ensure that people are only signing up once (admittedly potentially per email address they have).