Scenario: I am creating an application which uses OAuth for authentication and I want to try and limit a user sharing their credentials with colleagues (we charge per seat). The only way I could think of this was to store the IP with the token (although I'm aware multiple users from a single client could be on the same IP).
Is there a standard way of doing this in OAuth?
Not via any feature specific to OAuth. A valid user that logs on from the office or from home will have a different IP address. How would you distinguish that from another user that has someone else their credentials?
The only way I see to make this work is require two-factor authentication. It's much less likely your users will be prepared to share for example their phone to use your application.
Just make sure your application adds enough value that your users will want their own account and not share credentials.
Related
I am working for the DOD. The application they have requested is web based, and will be on their internal network. The request is for CAC authentication, which is easy enough... The remaining problem is authenticating a user. The CAC authentication is happening at the IIS level, so by the time the user gets to the application, all I am doing (or had planned on doing) is checking the ID on the CAC, and comparing it to a user table in the database. If the user exists (and has been approved), then they are off and running in the system. If they do not exist, then they are pushed to the registration screen.
Given my lack of experience with web development, I am unsure if I need to actually authenticate the user in some way beyond the CAC authentication, or if I can just manually assign roles to the user and let the roles dictate what can or cannot be done in the application. Windows authentication is not an option; while this application is internal for the military, it is accessible from different mil networks.
If I do indeed need to authenticate a user... this is where I run into trouble. I have not found anything that says there is a way to manually authenticate a user. I could use the standard ASP tables in the database, but it seems... messy... to include things that won't be used (meaning the password field would always be an empty string - why include it in the db if it isn't being used?).
Thanks in advance for any help... If there's links to where I can read more about the authentication process, those would be very much appreciated as will.
I'm working on several DOE projects that use the same idea. What we normally do for web applications is to enable Windows authentication on the app. This will allow pass-through of user credentials and keep out anyone without credentials.
I also like to add role based authorization into the mix and then use AD groups to allow/deny users on specific apps.
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.
Could anyone please share any thought on authenticating Active Directory users using the AuthType.Kerberos method.
Ideally, I would like to pass the Username and Password to validate the user credentials using the AuthType.Kerberos method
This type of validation uses LDAP connection (LdapConnection)
Any comments or feedback will be very appreciated.
Cheers! :)
Kerberos doesnt use a username and password in the sense you are talking about here, it uses a ticket based auth system with a central server. Kerberos is quite complicated to implement and is normally only used in cases where you want to do double hop authentication with the logged in user. This means the application wants to use the credentials of the user who has logged in to access a secondry system. For example if you have a SharePoint site which pulls data from exchange server you may want to pass the currently logged in users details from sharepoint to exchange. This is normally done with Kerberos and Constrained Delegation.
In reality what you probably want for your application is Windows authentication (NTLM) which allows the application to authenticate domain users, (However again in the common case this doesnt use a username and password at your application level either).
===EDIT===
To implement kerberos with a .Net webapp you will need to do the following
Enable Constrained delegation for the app pool http://blogs.msdn.com/b/dotnetremoting/archive/2006/07/06/662599.aspx
Setup SPN's for your site http://support.microsoft.com/kb/929650
Setup your code to use kerberos when you call the remote service, this is basically just setting the protocol. You dont need to actually send the username or password
This article has some good advice around how to troubleshoot problems with the system
http://blogs.technet.com/b/askds/archive/2008/05/29/kerberos-authentication-problems-service-principal-name-spn-issues-part-1.aspx
Just going to start making a web application and was wondering which was better, or at least what are the main differences between them (as it probably matters what I am using them for)?
Windows Authentication
Passport Authentication
Form Authentication
I would say it greatly depends on what your web app will be doing, as each one has its place. Here is some brief details about each one.
Windows authentication enables you to identify users without creating a custom page.
Credentials are stored in the Web server s local user database or an Active Directory domain. Once identified you can use the user s credentials to gain access to resources that are protected by Windows authorization.
Forms authentication enables you to identify users with a custom database such as an ASP.NET membership database. Alternatively you can implement your own custom database. Once authenticated
you can reference the roles the user is in to restrict access to portions of your Web site.
Passport authentication relies on a centralized service provided by Microsoft. Passport authentication identifies a user with using his or her e-mail address and a password and a single Passport account can be used with many different Web sites.
Passport authentication is primarily used for public Web sites with thousands of users.
Anonymous authentication does not require the user to provide credentials.
http://msdn.microsoft.com/en-us/library/eeyk640h.aspx - ASP.NET Authentication further details on forms and window authentication
Edit
Rushyo link is better: http://msdn.microsoft.com/en-us/library/ee817643.aspx
Situation as when you can use what :
Windows Authentication : As you will be using the login & password used in a domain... If you use windows authentication, your webapp will (generally) have to be deployed in a network server and all your users should (generally) have a login created for them in the domain. Though cross domain operations are possible, primarily you wont be able to use it in non-domain based environment like public websites. It will be tough if you want to include some users who are outside your domain.
Forms Authentication : Here you are deciding to act independently. You will assign each user a separate userId and password and will manage them yourself. The overhead here is you should provide and restrict the ways users are created and removed. Here you are not restricted to any domain. For any user to gain access to your webapp should get registered with your webapp. This is similar to any mail sites you see on internet.
Passport Authentication : You are depending on MS to validate your users. This will give you a global status to your application, but if you are going to deploy it only to a small group of users, you will be forcing them to create a passport account (if they don't have) so that they can access your application.
To make it more clear.. Whichever method you follow You can still restrict who can access your webapp, and can also define your own roles for each users.
This should cover everything you're looking for (and more):
http://msdn.microsoft.com/en-us/library/ee817643.aspx
[Snap - I was totally going to use that exact same quote as well ;)]
Windows Authentication : As you will be using the login & password used in a domain... If you use windows authentication, your webapp will (generally) have to be deployed in a network server and all your users should (generally) have a login created for them in the domain. Though cross domain operations are possible, primarily you wont be able to use it in non-domain based environment like public websites. It will be tough if you want to include some users who are outside your domain.
Forms Authentication : Here you are deciding to act independently. You will assign each user a separate userId and password and will manage them yourself. The overhead here is you should provide and restrict the ways users are created and removed. Here you are not restricted to any domain. For any user to gain access to your webapp should get registered with your webapp. This is similar to any mail sites you see on internet.
Passport Authentication : You are depending on MS to validate your users. This will give you a global status to your application, but if you are going to deploy it only to a small group of users, you will be forcing them to create a passport account (if they don't have) so that they can access your application.
To make it more clear.. Whichever method you follow You can still restrict who can access your webapp, and can also define your own roles for each users.
Right now we have AD/Exchange to manage all of our users logins/e-mail on-site at the office. The major app that everyone uses maintains its own login accounts and all users have a tendency to forget login information for at least one of the two logins.
What I'm considering doing is using AD to authenticate the user in the application so that they don't even have to login to the app after they've logged into their machine.
The problem is that there are small number of users that work off-site (the app can work over the internet) and just use the machine's local account (which is causing problems of its own).
What I'm wondering is, will using AD to authenticate users on-site still be an option if a user works off-site?
The answer to almost any question posed to a programmer is "Yes..." It's what comes after the ellipses that is important. You may not want to do the things that come after the ellipses.
Based on the information in your question I think the answer is "No" but there are several scenarios where we could change that to a "yes".
If the AD account is only being used to authenticate that a user knows the password, then you could make a web service, host it in your domain, set it up to use windows authentication and SSL, modify the application to prompt the user for credentials, and call a method in the web service using those credentials. In that scenario, a successful call to the web service means that the user is authenticated. You could use the user's credentials to continue from there.
Detecting weather the application needs to prompt the user for credentials or not could be done by attempting to call the web service with the user's logged in credentials first. If this call fails then you know you need to prompt the user.
Not knowing the rest of the details of your application however means that there are many scenarios where this would not be enough.
I have done something very similar to what I described above. My scenario was the reverse: the application worked over the internet but I wanted it to be easier to log in in the cases where the machine has domain membership.
As an aside, the members who work from home: are they using laptops that are part of the domain or are they using machines that are not connected? In this case you may be able to use cached credentials but you should ask that question over at ServerFault.
Yes, you can definitely do that. It'll be a bit of work though.
What your app would have to do is either find out automagically whether it's directly connected to the office LAN, or working away from the office. Or you could have the user tell you, of course :-)
If it's on the LAN, no problem - you authenticate against AD.
If it's away from the office, you could e.g. call a WCF service on the company LAN, pass your Windows credentials, and have it authenticate you against the company AD. If you provide the right set of credentials, you'll be authenticated and allowed to work - if you're not allowed to log in, the call to the WCF service would fail.
You could do this almost automatically by using Windows credentials - in which case the "remote" user would still have to log on to your domain and use his / her normal Windows credentials; or you can pass username/password over the wire to WCF, or even install a certificate on the remote user's machine that WCF will then map to an AD account on the server side.
The options are plentiful! :-)
Marc