Microsoft

Blog Categories

Subscribe to RSS feed

Archives

Posts Tagged ‘security’

Integrating ASP.NET MVC authentication with SiteMinder SSO

SiteMinder is an enterprise-class secure single sign-on solution by CA (Computer Associates) which is employed by many large companies to secure their intranet access and provide single sign-on functionality to various intranet applications.  SiteMinder has a broad support for different application frameworks which is making possible to use in heterogeneous enterprise environment.
For example, when SiteMinder is used to secure ASP.NET/IIS application then it’s normally configured as IIS handler. For example (in web.config):

<add name="handler-wa-32" path="*" verb="*" modules="IsapiModule" scriptProcessor="C:\Program Files\CA\webagent\win32\bin\ISAPI6WebAgent.dll" resourceType="Unspecified" requireAccess="None" preCondition="classicMode,bitness32" />
sso SiteMinder module is intercepting every request to ASP.NET application resource and authenticating and authorizing user. If user is authenticated and authorized successfully then SiteMinder is passing the request further down the pipeline to ASP.NET.
So, how too integrate SiteMinder authentication with ASP.NET MVC authentication? SiteMinder is doing a great job for handling it on it’s own, but quite often MVC application will need to doit’s own, custom authorization in order to grant or deny user access to different resources, depending on user role.

Read the rest of this post »

ASP.NET MVC anti-forgery token demystified – part 3: AJAX

AJAX This blog post is third and final in series about MVC anti-forgery (CSRF) token.
Part 1.
Part 2.As we talked about it earlier, MVC have a great built-in functionality for securing form posts with anti-forgery tokens and it’s even possible make it work across multiple web applications.

However, these days modern web applications tend to have more asynchronous (AJAX) communication between browser and web server   than traditional HTML form posts where the whole page is reloaded. The question is, can built-in MVC components to be used for CSRF validation when browser code is using AJAX to post to the server?

Obviously, it can’t be used directly because @Html.AntiForgeryToken only works when it’s placed inside HTML form and that form is submitted to the server. In case of AJAX post there is no form, so the AJAX controller method will not receive a form CSRF token (cookie token though will flow with the AJAX post normally).  However,  we can make it work with a little of extra coding…

Read the rest of this post »

ASP.NET MVC anti-forgery token demystified – part 2: inside

Mechanic-Under-Hood In the previous installment of this post series I talked about CSRF attack and how to prevent it using ASP.NET MVC built in components. Today I want to dive deeper into the framework code and show you what’s under the hood to anti-forgery token implementation in MVC.

Some time ago Microsoft took a huge step forward and open sourced complete ASP.NET MVC and Web API stack. Now developers can see what’s actually happens inside the framework and don’t have to rely solely on Microsoft documentation. The source code for MVC stack is located at http://aspnetwebstack.codeplex.com/.

As you recall, there are two components that provide CRSF protection when used together – AntiForgeryToken methjod of Html helper (@Html.AntiForgeryToken()) which should be called from inside HTML in Razor view and ValidateAntiForgeryTokenAttribute ([ValidateAntiForgeryToken]) which should be applied to controller to validate tokens. Both of these classes are actually a thin wrappers on top of the AntiForgery class. AntiForgery class is a static class which is encapsulating all functionality for generating and validating tokens. Source code could be found there. This is a public class and could be used directly if somebody will decide to implement a custom generation and validation of anti-forgery tokens. In turn, AntiForgery is using other helper classes like AntiForgeryWorker and TokenValidator. Unlike AntiForgery these classes are internal and can’t be used directly by application code.

So, why it’s important to look into internal implementation of anti-forgery token generation and validation?

Read the rest of this post »

ASP.NET MVC anti-forgery token demystified – part 1: what is it?

Securing your web application is now more important than ever because various security attacks are growing in numbers and becoming more sophisticated and frequent. One of the most common types of attacks is Cross Site Request Forgery (CSRF) attack. In this kind of attack malicious web sites are hijacking a previously authenticated user sessions to exploit your web site.csrf

Consider the following example: you web site is using ASP.NET Forms Authentication. User is authenticated on login page and user authenticated session is maintained using standard  .ASPXAUTH cookie. Without closing the browser window or logging off your site user is visiting a malicious site which  can (using social engineering, like displaying some sort of a false message to the user) now cross-post to your site (using a standard HTTP form post) and that post will be bearing a valid .ASPXAUTH cookie issued by your site. So, unless your web site employs some special measures, your web site server code will not be able to distinguish a valid post from your web site from a post from malicious site.  Note, that implementing HTTPS on every page your your site will not solve this issue as malicious site can post over HTTPS too. HTTPS can only prevent the traffic between your web site and web client to be hijacked and analyzed, but in case of CSRF attack the attacker doesn’t need to analyze your traffic, it just reuses the authenticated user session.

csrf - explained Read the rest of this post »

Coin — One card to rule them all?

What is Coin?  Coin is a brilliant new technology that allows users to consolidate all of their cards into a single Coin card.  A Coin card is not your traditional credit card.  It is an electronic device the size of a credit card with a programmable magnetic strip.  Any card with a magnetic strip whether that be a debit/credit card, gift card or preferred customer card, can be put on your Coin card.

The Coin card works over Bluetooth and is paired with your phone.  Using your phone and an adapter supplied by Coin, a user swipes their cards which gets loaded into your Coin account.  When a debit card is neededCoin Credit Card instead of a credit card, make the selection on your phone.  The Coin app will send the information to your card and it will be ready for use with that specific card information.  Loose your phone or your card?  Have your wallet stolen?  That is OK.  Coin has security configurations that will deactivate the card automatically if it loses communication with your phone for too long.  It sounds as if Coin has thought a lot about security, at least from the physical security point of view.  What about digitally?

We live in a world where data breach is common.  A new story about a large company being hacked with customer information stolen seems to happen semi-regularly.  Many times the stolen data is not encrypted and this non-encrypted data contains anything from credit card information to email addresses.  Is it safe to put all of my banking, credit and preferred customer information in a single location?  It is a risky move to digitally putting all your eggs in one basket.  If Coin was hacked and your data was stolen what would happen?  It is essentially the same thing as having your entire wallet stolen.

Coin appears to be prepared for this.  Coin does not state what user data is stored with them but they do state all user data in the cloud, on the mobile app or on the card itself  is encrypted using at least 128-bit encryption.  In addition any information transferred via Bluetooth is also encrypted so personal data could not be used if it were captured during transmission.  This means that if the data is stolen from the cloud, phone or card it is virtually worthless without the decryption key.

Coin has put the right foot forward in their vision of plastic card consolidation.  The strong encryption shows they are serious about data security.  With the configurable lockout and deactivation features they are making every effort to physically secure the device from theft or being lost.  The technology being used is not new but the way it is being used is both new and unique.  If Coin is as secure as they claim and the concept takes off expect the popularity to grow exponentially along with the copy cats.  The card itself is still in pre-order and is set to be released this summer.  You can find out more about Coin here.

A digital renaissance in public school innovation and technology

One of the primary methods that schools can innovate is with technology. I live in an area where they’re trying to provide technology to all students by providing laptops or tablets from kindergarten to seniors in high school, all grades K through 12. In any one school district they now have to manage these devices and make sure they are working correctly on a day-to-day basis or the students will not be able to complete their school work. The area I live in is calling this initiative the “Digital Renaissance”. Overall I think this is a great initiative, though I have several concerns.

Decision making on cost

As far as device choice goes schools are going to buy whatever they can get the best deal on. Which isn’t always going to provide the best device. This initiative is one area in which I believe Windows 8 and Surface-like devices could offer amazing benefits. I also believe device selection plays into other areas as well.

education

Security and consumerism in technology

The students being given devices to learn are now more like employees for the school system and should be treated as such. How will the schools secure the devices so that students can’t install applications or updates that don’t help with their studies? Most consumer-based devices will not have the features required to secure them properly and stop these “employees” from being able to improperly use these devices.

Students are going to try to find ways to use these devices in an unknown number of ways. Think of all the different ways children use smart phones and the trouble they get themselves into. To summarize, how is the school system going to filter the students’ activities on these devices? Read the rest of this post »

App model in SharePoint 2013 puts power in the developer’s hands

About two months ago, I was pointed to an article that talked about SharePoint Apps and how some people are starting to call them “Crapps”: SharePoint 2013 Preview – Apps or Crapps?  I didn’t want to add my two cents right away because I hadn’t really had a chance to play with the App Model in SharePoint 2013 and I didn’t want to sound sycophantic.

However, now that I’ve been deeply immersed in building a complex on-premise SharePoint 2013 app for the better part of 2 months, I find myself firmly in the “major improvement” camp.  In case you haven’t read Doug Ware’s article, I’ll summarize it here briefly:

Doug talks about how, in SharePoint 2010, Sandboxed Solutions were supposed to be so amazing and make everything better and it turned out that Sandboxed Solutions actually had too many limitations to be useful for a lot of work streams and that the same thing could happen with Apps.  In addition, he points out that people like creating Farm Solutions, the concept of clean deletion is broken because SharePoint is not a phone, and there are no guidelines for creating apps yet.  In the end, he decides that the devil is in the details with how you create the app. Read the rest of this post »

Planning for Externalizing Authentication in SharePoint 2010: Part 1 – Introduction

Since the beginning of 2011, I’ve had the good fortune of being involved with several projects involving the claims authentication capabilities introduced in SharePoint 2010. The scope of these efforts have ranged from small proof-of-concept demonstrations to large Internet and Intranet production deployments. Some involved custom built Security Token Services (STS) and others relied on vendor-provided products like ADFS 2.0 and Ping Federate. As a sort of unofficial evangelist for this sort of thing, I’m impressed with how architects and developers, both from our consultants here at PointBridge and with our customers, have embraced the concept. In pretty much every case, we had a slightly different problem to solve and the technology has enabled us to deal with it in a straightforward way. Folks out there are “getting it” and I’m looking forward to helping advance this technology even further as we begin the new year.

So I thought this would be a good opportunity to share what are in my mind the key planning considerations when opting to use this approach for authentication. Note that for the purposes of this writing, when I say “externalizing authentication” I’m really talking about what Microsoft refers to as using “SAML claims”. In other words, using some sort of external STS (like ADFS 2.0 or Ping Federate) that issues tokens to be consumed by SharePoint for authentication.

What Do I Need to Plan For?

This can quickly become a pretty large and technical subject to discuss, so I’ll break this blog series into the main planning areas that I see need to be addressed:

  1. Authentication and Authorization: Identity Providers, STS, SAML tokens, claims, custom claims provider, web applications, zones
  2. Session Management: Token cache, sliding sessions, cookies
  3. Functionality: Custom controls and pages, Office integration, search
  4. Operations: Support processes and documentation

Note that in this series I won’t be covering much regarding the specifics for configuring external authentication for SharePoint 2010. That’s already well covered in previous posts I’ve written and also the following Microsoft whitepaper: Implementing Claims-Based Authentication with SharePoint Server 2010. Additionally, the recently released 2nd edition of “A Guide to Claims-Based Identity and Access Control” is pretty much required reading for anyone looking to get involved with this technology. My focus is going to be on what we’ve seen out there in the “real world”.

Before starting, have clear design objectives

Externalizing authentication will force your team to solve some things that are taken for granted when using traditional Windows-integrated authentication. Additional investments in time for development, testing, documentation, and operational procedures will be required to to ensure short and long term success. Therefore, I believe a strong justification for this approach is required. Externalizing authentication could be a good choice if the organization:

  1. Requires Single Sign On (SSO) or Web Sign On (OpenID, Facebook, Twitter, Google, etc…) with vendors or customers. Because SAML is “standards based” and provides a very high degree of interoperability, this is a common justification.
  2. Is undergoing a lot of transition with its directory services (acquisitions and migrations) and doesn’t want to be limited or held back by these changes. Externalizing authentication to a single “identity tier” creates a façade that enables SharePoint projects to move forward without being held hostage to other organizational initiatives.
  3. Does not have a centralized identity infrastructure and never will. It operates more as a federation of entities and interested parties and still wants to take advantage of SharePoint as a collaboration platform.
  4. Wishes to expose SharePoint 2010 to mobile devices.
  5. Requires one of more of it’s SharePoint sites to work like a banking banking site with automated sign-out during idle times and doesn’t have expertise to accomplish this at the gateway (firewalls / reverse proxies).
  6. Is looking to consolidate its web tier assets under a single identity infrastructure and enable more interoperability between applications. Claims authentication is fully supported in ASP.NET and Windows Communication Foundation, including REST web services. For obvious security reasons, this makes sense to standardize under a single authentication and authorization scheme, especially one that is as flexible as the various SAML-related protocols out there (WS-Trust and WS-Federation).
  7. Is making a commitment to “the cloud”. Because claims authentication fundamentally works with the web, it can be used to tie together on- and off-premise applications in a seamless manner. And this goes for SaaS solutions like Microsoft Office 365, which utilizes ADFS 2.0 to achieve SSO with your local instance of Active Directory.

These are just a few common examples….and in most cases more than one scenario would apply to a given project. I mention all this because I believe it’s important to always “keep an eye on the prize” when fighting through all the details and nuances that externalizing authentication requires.

So….does it work?

I get this question a lot. The short answer is: “Yes, but with some effort”. We here at PointBridge have several customers in production today using SAML claims – with some implementations going pretty deep into the search and collaboration features. But as I mentioned above, a successful result may require implementing a series of customizations to SharePoint; some of them minor and others more substantial. For example, the reality is that any production-quality deployment is going to need to implement a custom People Picker to resolve what the user enters to something real (a group or user account in AD, LDAP, or SQL). That’s not available out of the box and will require code. Fortunately, there are great examples out there on the ‘net to get you started.

SAML claims requires each user to have an attribute that uniquely identifies the account. Your team will have to take a hard look at the Identity Provider (Active Directory in many cases) to ensure this attribute exists and is 100% populated (and standardized). If the attribute involves a given name or surname, you will need to call out processes to handle name changes. An unhandled name change will result in a new user account in SharePoint and a whole lotta confusion for all parties involved.

Depending on your level of sensitivity to the end-user experience, you may find you’ll need to customize several SharePoint administrative pages such as the default “Access Denied” and “Request Access” pages, which by default expose the unfriendly claims identity of the end-user (example: 0e.t|externalprovider|joe.user@corpdomain.com). You may also find that you’ll need to update extra controls such as the “Sign Out” and “Sign on as a different user” components in the Welcome Menu control.

If your environment is going to support document management functionality, your team will need a solid understanding of the relationship between session cookies and the various versions of Microsoft Office.

Search (both FAST for SharePoint and standard search) will require that your web applications have a specific zone configuration so that content can be indexed. This configuratio
n may drive other “fixes” to ensure automatically generated links such as workflow task alerts point the the URL you want your end users to see.

Out of the box, tokens for authenticated sessions are stored in memory on each Web Front End. If you’re working in a multi- WFE farm topology and don’t have sticky sessions available…or your system has any sort of vulnerability to unplanned app pool recycles (which is probably everybody :) ) , you should consider implementing a persistent token cache as opposed to relying on what Microsoft gives you.

And there are a couple of things you’ll have to give up. The Document Preview functionality in FAST for SharePoint is one of them.

Almost all of these things can be addressed….and I’ll cover that in future posts in this series. My point here is you should look at the advantages SAML claims brings to the table versus any risks and costs associated before jumping in. Obviously, this sort of evaluation is necessary for almost any newer technology and externalizing authentication is no different.

Microsoft //BUILD Conference Webinar #2– How Windows 8 / Metro will Affect Enterprise IT, and How You Can Prepare

Date: October 27, 2011

Time: 1:00-2:00 PM EST

Register Now! http://microsoftbuild2.eventbrite.com/

microsoftpic

We have changed the date of this webinar to October 27, 2011.

Windows 8 is a product that is initially both exhilarating and confusing. The Metro Style UI first experienced in Windows Phone 7 is at the forefront of Windows 8. It is fresh and inviting to the user while providing the information users need to keep up to date without drilling into applications. One of Perficient’s Microsoft experts, Chris Woodruff, has compiled details and analysis from the BUILD conference. Chris is a member of Perficient’s Microsoft Competency Center specializing in Application Architecture and Development, and he leads technical business development for Windows Azure.

On the server side there are also changes coming with the new announcements regarding Windows 8 Server. Windows Server 8 will allow IT shops and Enterprises to build and manage infrastructure for large multi-tenant Clouds, drastically increase scalability and reliability in the areas of Virtualization, Networking, Clustering and Storage, as well as have significant security improvements and enhancements.

Chris attended the BUILD conference and many of the Windows Server 8 sessions regarding this exciting upcoming Windows release. In the second webinar in this four-part series, Chris will provide an glimpse of what is coming for enterprise customers and Windows users as well as how internal IT and enterprise development teams can leverage the news coming from //BUILD about Windows 8 and Windows Server 8.

403 Forbidden Error with iPhone When Accessing SharePoint 2010 in Claims Mode

If you’re looking to support iPhone on a SharePoint 2010 site that is configured to use an external identity provider like Ping Federate, ADFS 2.0, or a custom STS, you will likely run into this issue. However, you may notice everything works just fine with iPad. Fortunately, the issue can be reproduced on the desktop using Firefox or Safari by emulating the iPhone user agent and you’ll be able to see what’s going on in Fiddler.

image

As seen in the above screenshot, you’ll notice an additional redirect to /_layouts/mobile/mblmultilogin.aspx just before hitting the /_trust/default.aspx page. And indeed this is what causes the issue. To correct it, you’ll need to update iPhone Safari section within the Web Application’s compat.browser file and set the “isMobileDevice” property to false.

clip_image001

After making this change, your iPhone users should be able to enjoy the SharePoint experience from their phones. Yeah, that was a bit of sarcasm there….