What are the pros and cons of Azure Active Directory to manage the accounts of a simple website (at most 10 accounts, just for login to control panel), instead of SQL membership provider or the new bogus identity system in my own database. I never tried this service before but I like the fact that I don't need to take care of the database and credentials of my users, it's free and very secure I guess. Someone has tested it in production? any security advise? thanks.
Among the many upsides there's that it is free, highly available, enterprise-grade and basically management-free - all flows for entering and changing passwords and similar are already implemented for you. Also, it can be used for both web sites and web API - so that if tomorrow you want to add a mobile app for the same user population, we've got you covered.
About having tested it in production... yes, there are many many (MANY) apps using AAD in production today.
I guess that one possible downside for such a small use case is that all the defaults are set to a higher security level than you'd probably use in your scenario, translating in a bit more involvement from your users: passwords templates requiring special characters, mandatory password expiration, and so on. Of course to me it's a good thing, but I am biased :-)
Another current limitation is that the user names must be of the form alias#yourADdomain, as of today you cannot use an arbitrary string. That's usually not a big deal, but calling it out in case you have preexisting user names you need to stick to.
HTH
V.
Related
I'm totally new to SAML. I want implement SSO for my ASP.NET Website. I got the SAML assertion from my client. I would like to know what are all other requirements I need to get it from my client and what setup I need to implement at my end.
Can anybody help me out in this.
Thanks in advance.
The first thing that I would do is avoid writing the SAML code yourself. There's plenty out there. #Woloski (above) has some. My company has some (I work for the company that makes PingFederate). There's some open source stuff, too. I've seen good connections from KentorIT authServices. If this is your first foray into SAML, then my bet is that ADFS is way overboard. I'll be honest, the groups we see most commonly at Ping is when they decide to go "all in" with SSO. The first one or two connections are easy. Tehn it becomes a management nightmare rapidly thereafter. The reason I say to avoid writing your own, is because there are a LOT of nuances to SAML, with massive pitfalls, and headaches you just don't need.
As the service provider (SP), you need to tell your client (Identity Provider, or IdP) what "attributes" you need from them to properly connect their users to their account in your application (maybe a username?). In addition, you can ask for additional attributes to ensure their profile is up to date - phone number, email, etc. It's up to the two of you to determine what you need (and what they'll give you). Obviously, they shouldn't send social security number, if you have no need for it.
You also need to decide if you will do SP initiated SSO (will the users get links to documents deep inside your app?), or if just IdP initiated (Or will always just come to the front door?) will suffice. What about Single Logout? Do you (or they) want to do that? [Personally, I suggest NO, but that's a different topic]
What about signing the assertion? Your cert or theirs? If you're doing SP-init, do you need to use their cert or yours for signing the AuthnRequest? Do you need encryption of the assertion, or maybe just a few of the attributes?
Generally, you do all of this with a "metadata exchange". You give them your metadata that says "this is what we need". They import that metadata to build a new connection, fulfilling the attributes your app needs with calls to their LDAP or other user repository, as well as doing authentication (if required). They finish building their connection, and export THEIR metadata, which you import to build your connection (thereby making sure you all agree on certificates). You hook it to your app, and away you go.
I make this sound easy. It is, and it isn't. Rolling your own can mean issues. Lots of them. With some being so minute that it takes pros hours (and days) to see it. When it works, it works, and well.
HTH -- Andy
you can use something like ADFS to accepto SAML Assertions. ADFS gets installed on Windows 2008 or 2012.
You would need to ask your customer
the signing certificate public key and
the sign in URL.
Then you would create a "Claims Provider Trust" in ADFS and enter those details. Then a "Relying Party Trust" that represents your application. Finally you would have to configure your application with ADFS using WIF. This blog post have more details:
http://thedotnethub.blogspot.com.ar/2012/12/adfs-20-by-example-part1-adfs-as-ip-sts.html
Also you can use Auth0 to accomplish the same without setting up any software on your side (disclaimer: I work there).
We have an internal CRM system which is currently a website that can only be accessed inside our intranet. The boss is now wanting to have it exposed to the outside world so that people can use it from home and on the road. My concern is security based in the fact we will be exposing our Customer base to the outside world. I have implemented 3 layers of security as follows:
User Name and Strong password combination to login
SSL on all data being pushed across the line
Once the user is logged in and authenticated the server passes them a token which must be used in all communication with the server from than on.
Basically Im a bit of newb in the respect of web security. Can anyone give me advice on whether I am missing anything? Or something should be changed?
There's a whole world of stuff you should consider, and it'll be really hard to quickly answer this - so I'll point you at a range of resources that should help you out / get you started.
First, I'll plug http://security.stackexchange.com, for any specific questions you have - they could be a great help.
Now, on to more immediate things you should check:
Are your systems behind a firewall? I'd recommend at least your DB is placed on a server that is not directly available to the outside world.
Explore and run a range of (free) security tools against your site to try and find any problems. e.g.:
https://asafaweb.com
http://sectools.org/
Read up on common exploits (e.g. SQL injection) and make sure you are guarding against them:
https://www.owasp.org/index.php/Top_10_2010-Main
https://www.owasp.org/index.php/Category:Vulnerability
How is your token being passed around, and what happens to it if another user gets hold of it (e.g. after it being cached on another machine)?
Make sure you have a decent password protection policy (decent complexity, protects against brute force attacks by locking accounts after 3 attempts).
If this is a massive concern for you (consider the risk to your business in a worst case scenario) consider getting an expert in, or someone to run a security test against your systems?
Or, as mrunion excellently points out in the comments above (+1), have you considered other more secure ways of opening this up, so that you don't need to publish this on the web?
Hope that gets you started.
I am deploying an ASP.NET application and SQL Server (2008) database on a live (production) server. The physical server is running both SQL Server 2008 and IIS 7 - it is provided by a hosting company and is not part of our internal network.
I have a couple of questions regarding database security and the connection string for the ASP.NET application.
Previously I would create a database user and specify the SELECT/INSERT etc. permissions for each table - but my issue is that there are 50+ tables in this database, so doing this would take a long time.
The application requires SELECT/INSERT/DELETE/UPDATE on each table.
Is there a better way than specifying the permissions for each table individually?
Is there an equivalent of integrated security for a live web server - what are the drawbacks?
Or is there a way of elevating the access rights for a particular user to full access for a particular database
Also how would the connection string change?
I just looking for some expert advice, just someone to point me in the right direction and a link to some documentation on how to achieve a better way of doing it.
Many thanks.
You have essentially three unrelated questions in your bullet list, not one.
The first one is a better fit at ServerFault.com, as it deals with SQL Server, not necessarily a programming question.
However, Google paid off, and here's a method for doing it: http://www.tech-recipes.com/rx/2298/sql_server_2005_easily_grant_select_all_tables_views/
Alternatively, you can just assign the user to the correct groups as described in #Oded's answer here: TSQL granting read and write permissions to all tables
For the second one, Integrated Security, yes, there is a way to use integrated Security with ASP.NET. See this article: http://msdn.microsoft.com/en-us/library/bsz5788z.aspx
The biggest drawback is that it's more to configure. it's a non-standard (but supported) configuration, so maintenance programmers may not have seen the setup before.
Also, if you're doing this, there could be security concerns if you're using an account that has permissions elsewhere. Be sure to follow the principle of least privilege. It might be best to create a Domain account specifically for each website, so if one gets compromised, it limits the damage that can be done. You know your security concerns better than I do, so this may or may not be relevant advice, but it's something to consider.
Finally, (and this is probably too obvious to point out) it would be foolish to use a real person's UserId. If that person leaves the company and their account is removed, the website will obviously break.
Now that I've found an answer for the first question, the third one becomes moot.
You can create or use an existing database role. Then you put the user into that role to allow that user to have all the permissions you need. For example, you might put the user account you are using in your connection into the db_datawriter role given the scenarios you described.
See http://msdn.microsoft.com/en-us/library/ms189121%28v=sql.105%29.aspx
This article also related to how you could elevate a user's permissions.
Integrated security will work--it just requires that the login used on the computer that is making the connection be recognizable by the database server (in the same or in a trusting Windows domain).
Are there any alternatives\mods to .net Membership?
I find it quite restrictive;
Cant change Username, easily. You have to create a new user and copy the fields, but then you lose the primary key OR you have to edit the user table directly yourself.
Additional profile fields are stored together as one blob.
ASP.Net membership uses a provider model. That means you are completely free to implement your own membership provider, or even inherit from and extend an existing provider, as long as you follow the provider contract.
Plus one for asking about existing alternatives rather than trying to build something new yourself, though.
I'll go ahead and list my alternative here. I've rolled my own authentication library, and I think it's awesome enough to be publicly released... So I did. It's designed to stay out of your way and overall, it's pretty minimalistic. I don't provide a lot of out of the box user controls, but on most websites I've seen those built-in user controls are never used. So instead of trying to make yet more flexible user controls, I decided instead to make it brain-dead simple to create your own login controls and such.
The project is called Fast, Secure, and Concise Authentication, or FSCAuth for short. It is BSD licensed. You can download it over at Binpress or at Bitbucket
It's flexible "UserStore" model(the Form's equivalent of provider) enables you to form your database anyway you want. It can support plain text files, XML, MongoDB, Sql Server, and anywhere in-between.
Here's a list of things where I think it particularly excels over Forms Authentication:
Stateless Authentication System. There is no requirement to keep track of user sessions in either the database or memory. This makes it trivial to scale up to multiple servers requiring few(if any) changes to your authentication code
Use anything as a Unique ID for each user. That's right, no more GUIDs! Anything that will fit in a string is fair game
HTTP Basic Authentication baked in. You can enable Basic Authentication just on pages you want(or globally) and you can make the same calls as if they were using the typical cookie-based authentication
Hard to make insecure. Because of how it works and I leave as little core-code as possible to the end user for actually doing authentication, it's extremely secure and will stay that way unless you just really try to break it. I handle cookies, HTTP Basic Auth, and all hashing. You just give FSCAuth a database to put it in.
BCrypt support for hashes is trivial. How to do it.. In Forms Authentication it is almost not possible
I like it :)
Of course it's also lacking, and to be fair I'll include a few things that are lacking
Authenticating static files in IIS 6 isn't possible(yet)
There is no brute-force prevention(yet). This means that you'll need to make sure the same person isn't trying to hit your login page 200 times in 2 seconds.
It's not built into ASP.Net
No Windows or Passport authentication (with no plans to ever add)
As the ASP.NET membership model is built around Providers, there are a number of alternatives available.
By default, users have a ProviderUserKey, which is a GUID, and that's the Primary key of the database, so you should be able to write something to change their username if you want.
In terms of the profile, yes, the default blob is fairly annoying. You could take a look at the SQL Table Profile Provider which maps profiles on to tables, or fairly quickly roll your own.
As for the Profile there are a couple of alternatives out there. These two use either a table or let you call a stored procedure. Of course you can also implement your own. I personally got tired of using the Profile Providers, and found that dealing with the profile in my code was easier to control and contain.
As for the other issues, you can also implement your own provider. Microsoft released the source code to the SQL Providers so it can give you a starting point.
As far as changing the username goes, that can easily be accomplished by using the CreateNewUser() method and filling in the appropriate fields based on the current User, and then deleting the current user.
Profile fields are not part of the .NET Membership Provider model, but part of the Profile Provider. This is a highly debated topic and for most production machines, the correct way to go is to drop-in a better profile provider solution, such as this Table Profile Provider, which stores profile fields as you'd expect rather than as a memory-hogging blob. Alternatively, you can easily roll your own profile provider, check out the instructions here.
There are certainly .NET Membership alternatives, but most are buggy or have a small featureset. It really sucks to develop on top of one for two months and then realize it won't support all the functionality you need. .NET Membership is a proven solution and that's why it is used so often.
I am looking for a best practice for End to End Authentication for internal Web Applications to the Database layer.
The most common scenario I have seen is to use a single SQL account with the permissions set to what is required by the application. This account is used by all application calls. Then when people require access over the database via query tools or such a separate Group is created with the query access and people are given access to that group.
The other scenario I have seen is to use complete Windows Authentication End to End. So the users themselves are added to groups which have all the permissions set so the user is able to update and change outside the parameters of the application. This normally involves securing people down to the appropriate stored procedures so they aren't updating the tables directly.
The first scenario seems relatively easily to maintain but raises concerns if there is a security hole in the application then the whole database is compromised.
The second scenario seems more secure but has the opposite concern of having to much business logic in stored procedures on the database. This seems to limit the use of the some really cool technologies like Nhibernate and LINQ. However in this day and age where people can use data in so many different ways we don't foresee e.g. mash-ups etc is this the best approach.
Dale - That's it exactly. If you want to provide access to the underlying data store to those users then do it via services. And in my experience, it is those experienced computer users coming out of Uni/College that damage things the most. As the saying goes, they know just enough to be dangerous.
If they want to automate part of their job, and they can display they have the requisite knowledge, then go ahead, grant their domain account access to the backend. That way anything they do via their little VBA automation is tied to their account and you know exactly who to go look at when the data gets hosed.
My basic point is that the database is the proverbial holy grail of the application. You want as few fingers in that particular pie as possible.
As a consultant, whenever I hear that someone has allowed normal users into the database, my eyes light up because I know it's going to end up being a big paycheck for me when I get called to fix it.
Personally, I don't want normal end users in the database. For an intranet application (especially one which resides on a Domain) I would provide a single account for application access to the database which only has those rights which are needed for the application to function.
Access to the application would then be controlled via the user's domain account (turn off anonymous access in IIS, etc.).
IF a user needs, and can justify, direct access to the database, then their domain account would be given access to the database, and they can log into the DBMS using the appropriate tools.
I've been responsible for developing several internal web applications over the past year.
Our solution was using Windows Authentication (Active Directory or LDAP).
Our purpose was merely to allow a simple login using an existing company ID/password. We also wanted to make sure that the existing department would still be responsible for verifying and managing access permissions.
While I can't answer the argument concerning Nhibernate or LINQ, unless you have a specific killer feature these things can implement, Active Directory or LDAP are simple enough to implement and maintain that it's worth trying.
I agree with Stephen Wrighton. Domain security is the way to go. If you would like to use mashups and what-not, you can expose parts of the database via a machine-readable RESTful interface. SubSonic has one built in.
Stephen - Keeping normal end users out of the database is nice but I am wondering if in this day and age with so many experienced computer users coming out of University / College if this the right path. If someone wants to automate part of their job which includes a VBA update to a database which I allow them to do via the normal application are we losing gains by restricting their access in this way.
I guess the other path implied here is you could open up the Application via services and then secure those services via groups and still keep the users separated from the database.
Then via delegation you can allow departments to control access to their own accounts via the groups as per Jonathan's post.