Kerberos, NTLM, forms, claims based, use of active directory?
Going through the difficult process of analyzing which authentication method to use for a Sharepoint build-out, and I must be honest in saying that I'm confused as to which the best use-case would be. It's going to be used as an intranet and extranet, and am wondering what authentication methods other people are using and why they chose the authentication method they did.
Many thanks!
We use claims based kerberos.
Claims based because we started with Windows authentication, but want to leave the option for enabling forms based authentication open. (Forms based authentication is not available in classic mode)
Kerberos because it allows us to overcome the double-hop problem.
Setting up Kerberos brings some additional configuration requirements. Although it may seem intimidating at first, it is well documented: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=1a794fb5-77d0-475c-8738-ea04d3de1147&displaylang=en
Also claims based authentication has it's problems/limitations, but until now I didn't encounter something that made me change my mind about it.
In your case, if you want to make your SharePoint available as an extranet environment, you may want to go for claims based authentication. That way you can use Windows authentication for internal people and forms authentication for external people (customers/suppliers/...).
When making integrations NTLM is the preferred one, Kerberos is nice (and safer) but if the AD goes down your intranets and extranets wont be accessible.
So, Kerberos if you are paranoid, NTLM if you want high availability and good enough security.
Related
I have external customers with their own intranet sites that have links to our web application. Once their employees have logged into their intranet they don't want them to have to enter separate credentials when they follow the links to us.
What are some options for offering a single sign on for them such that we bear the majority of the technical cost for setup and that we can use with as many customers as we want. Seems like it should be a solved problem but I have not been able to find an appropriate solution (other than coming up with something completely custom).
To be clear, employees already have accounts on our application.
You don't specify which platform you are on, but you should look into authentication federation. The idea is that their intranet site produces a security token that you trust to authenticate their users on your site.
On the Windows platform, WS-Federation is typically used. On non-Windows platforms, the SAML protocol is more popular. Security protocol can use different token formats like SAML or JWT.
After further investigation, I finally found some standard protocols for doing this:
JWT - http://www.intridea.com/blog/2013/11/7/json-web-token-the-useful-little-standard-you-haven-t-heard-about
SAML - http://wso2.com/library/articles/2014/02/introduction-to-security-assertion-markup-language-2.0/
For my purposes, I think JWT is best because it requires the least amount of effort to integrate.
More generally, who is successfully using WIF/ADFS/SSO on the Windows platform, and is it worth implementing, and what is the likeliness it will be a lasting technology?
On the surface, from reading a few whitepapers (PDF), articles and books on the subject, this seems like the perfect solution -- especially for a company that has an internal web site that exposes some level of functionality to external users and partners as well (or plans to in the future). But it sounds almost too perfect. And most of the information I have comes from Microsoft themselves.
I guess my specific questions are:
Is this a lasting technology and worth investing in (and specifically for a smaller sized (<50 ppl) company)?
Are there any major companies out there that are actively using this?
How likely is it that a partner would be willing to setup an STS if we wanted someone else to provide authentication for their company as a trusted issuer? Is there going to be a lot of push-back here?
Is this going to end up being a configuration nightmare?
Are there any other pitfalls to look out for when deciding whether to implement this?
As more applications are moved to the cloud and to online services you will see ADFS and other federated identity technologies increase in usage. Organizations with investments in Active Directory will likely move to this solution due the low cost of ownership.
Is this a lasting technology and worth investing in (and specifically for a smaller sized (<50 ppl) company)?
If you plan on either providing hosted services to other companies or plan on taking advantage of them yourselves ADFS provides a fairly painless way to take advantage of your current security infrastructure.
If properly implemented it should be fairly simple to replace on federation product with another.
Are there any major companies out there that are actively using this?
I'm only familiar with a government organization I've worked on, but I'm sure there are others. The nature of federated identity make if difficult to externally identify who.
How likely is it that a partner would be willing to setup an STS if we wanted someone else to provide authentication for their company as a trusted issuer? Is there going to be a lot of push-back here?
Is this going to end up being a configuration nightmare?
Configuration is the most difficult part of ADFS. However, once you have the trust relationships built and policies created configuration will be hands off.
Other companies will either have the infrastructure in place to support ADFS or won't. Even .NET applications require configuration changes to support ADFS and more likely will require code changes to fully support the federated identity model. If your partners have this in place it is likely they'll happily trust your STS.
Ask your what your partners have in place, they may already have or be planning infrastructure today.
Are there any other pitfalls to look out for when deciding whether to implement this?
The most difficult problem I ran into was changing application developer practices.
Applications need to either be designed around Federation or will need to be retrofitted with it.
You can't logout of an ADFS application without logging out of all ADFS applications.
When a federated session expires you must send a user back to the federation service for a new ticket. This could cause loss of post data if not handled properly.
From my experience:
In conjunction with WIF, ADFS offers:
Standard "outsourced" authentication / authorisation for ASP.NET applications. Once the applications are claims aware, you can make changes on the ADFS / ACS side and the application doesn't change.
Provides federation facilities with non .NET solutions e.g. OpenSSO and Tivoli.
Allows (via ACS) use of existing logins e.g. Facebook / Google.
Provides potential for applications to migrate to the cloud (Azure).
Standard claims-aware functionality for Sharepoint 2010.
The implementations I've seen are mainly for larger companies trying to put some kind of overall I&AM in place. It's especially useful when companies have both .Net and Java applications in place.
Also in NZ, we have an igovt login which provides one login to all governments departments and this is a possible candidate for "use an existing login" rather than creating a company specific one. igovt can federate with ADFS.
Main pitfall in my experience is that it doesn't work for classic ASP. It has to be ASP.NET.
To answer your other questions:
Larger companies who want to allow external access to their applications would far rather implement an STS than provision external users in their identity repository.
Configuration is not trivial but certainly doesn't become a nightmare.
I'm developing an ASP.NET MVC site that utilizes forms authentication for part of the application. During development, I need to be able to give external parties access to a development server hosting the site. Since I don't want to expose the site to the entire internet, I need to password protect it while still allowing forms authentication to be in use.
Mixing of Windows and forms authentication doesn't work. Is there a standard way of doing this? I would have to think this is a common scenario. The article on MSDN doesn't seem to apply to my situation: http://msdn.microsoft.com/en-us/library/ms972958.aspx
Update: The first two answers suggest adding in standard IIS basic/digest authentication. As far as I know, this is not compatible with forms authentication because the user's identity will be set to the Windows account, not the identity used through forms authentication. I need the two to be completely independent. Any thoughts?
You could protect it in IIS, give those details to the external parties, and leave the forms auth as it is.
Disable anonomous access to force the users to login via a windows account before accessing the site.
I knew a guy who did this using Apache and a reverse proxy.
http://www.apachetutor.org/admin/reverseproxies
Well unfortunately what you're trying to do is not possible in IIS7 (integrated mode), but there is a workaround. I suggest you to read this article written by Mike Volodarsky a former program manager for IIS7 at Microsoft. Article addresses your problem and there is even a sample code you could use.
Are there any open source centralized authorization services available? There are lots of solutions for centralizing the authentication information (eg: CAS and JOSSO), but what about the authorization information?
There are some really good authorization frameworks (eg: Spring Security (formerly Acegi) and Seam Security), but it seems that I have to composite these into individual tiers or services. In other words, I can't run them standalone very easily. With a SOA, it seems like it would be very valuable to centralize not just the authentication but the authorization information as well (ie: roles, permissions, rules, etc.).
Any suggestions?
Are you looking for something that supports XACML? If so, the closest to open source you can get is the OpenSSO project which has portions of what you seek.
The openly available Kerberos implementations provide Client Service Authorization as well as Client Authentication.
Read about Using Kerberos 5 on Red Hat Linux.
Hum, maybe you can use a SSO solution and create a service which returns all the authorization information (roles, permissions, rules, etc) and make each application use this service to get each authenticated user authorization information.
So I like the OpenID idea. I support it on my site, and use it wherever it's possible (like here!). But I am not clear about one thing.
A site that supports OpenID basically accepts any OpenID provider out there, right? How does that work with sites that want to reduce bot-signups? What's to stop a malicious OpenID provider from setting up unlimited bot IDs automatically?
I have some ideas, and will post them as a possible answer, but I was wondering if anyone can see something obvious that I've missed?
You have confused two different things - identification and authorization. Just because you know who somebody is, it doesn't mean you have to automatically give them permission to do anything. Simon Willison covers this nicely in An OpenID is not an account! More discussion on whitelisting is available in Social whitelisting with OpenID.
The short answer to your question is, "It doesn't." OpenID deliberately provides only a mechanism for having a centralized authentication site; it's up to you to decide which OpenID providers you personally consider acceptable. For example, Microsoft recently decided to allow OpenID on its Healthvault site only from a select few providers. A company may decide only to allow OpenID logins from its LDAP-backed access point, a government agency may only accept OpenIDs from biometrics-backed sites, and a blog might only accept TypePad due to their intense spam vetting.
There seems to be a lot of confusion over OpenID. Its original goal was simply to provide a standard login mechanism so that, when I need a secure login mechanism, I can select from any or all OpenID providers to handle that for me. Allowing anyone anywhere to set up their own trusted OpenID provider was never the goal. Doing the second effectively is impossible—after all, even with encryption, there's no reason you can't set up your own provider to securely lie and say it's authenticating whomever you want. Having a single, standardized login mechanism is itself already a great step forward.
OpenId isn't much more than the username and password a user selects when registering for your site. You don't rely on the OpenId framework to weed out bots; your registration system should still be doing that.
Possible solution - you can still ask new IDs to pass a CAPTCHA test. Just like bots can sign up with fake/multiple email addresses to any site, but fail the "verification" step there as well.
Or are we going to have to start maintaining provider blacklists? Those won't really work very well, given how trivially easy it is to set up a new provider.
As far as I can tell, OpenID addresses only identification, not authorization. Stopping bots is a matter of authorization.
Notice that unlike conventional "per site" logins, OpenID gives you an identity that potentially transcends individual sites. Better yet, this identity is even a URI so its perfect for using with RDF to exchange or query arbitrary metadata about the identity.
You can do a few things with an OpenID that you can't do with a conventional username from a new user.
Firstly you can do some simple whitelist operations. If *.bigcorp.example are OpenIDs from Big Corp employees and you know Big Corp aren't spammers, then you can whitelist those OpenIDs. This ought to work well for sites that are semi-closed, maybe it's a social site for current and past employees.
Better though, you can make inferences from the other places that specific OpenID has been used. Suppose you have a map of OpenIDs to reputation values from Stackoverflow.com. When someone shows up at your web forum with an OpenID, you can see if they have decent reputation at Stackoverflow and skip the CAPTCHA or probationary period for those users.