RSA Conference 2013 – Confirming Two-factor Hesitations

Being at the RSA Conference this week has allowed us to confirm many of the issues we have discovered in the two-factor market as to why it is not being widely implemented by organizations. Many visitors to our booth, #248, were glad to share their frustrations of two-factor being too expensive, difficult for users to utili
ze, and unable to fit all of their access scenarios. Many have hardware tokens in place at great expense. As our previous blog posting “Are You For or Against Two-factor Authentication?” highlighted there are conflicting opinions on whether two-factor is needed due to the barriers that an organization would have to have in place to overcome them. The main objections we have heard to why you haven’t implemented two-factor authentication are:

  • I can’t distribute the tokens
  • I cannot justify the expense
  • I need my security configured first
  • It’s too difficult for my users to use
  • I have no buy-in from management
  • My data isn’t sensitive enough to protect
  • USB ports are not always available for tokens
  • It stops only basic attacks not serious blackhats
  • It doesn’t integrate with all of my systems

To knock down those barriers we have been promoting our alternative to two-factor PassiveKey. If you’re at the show, stop by to learn more.

Excuses to Avoid Two-Factor Authentication

Even with the promise of increased security that two-factor authentication (2FA) brings to applications, there are still legitimate concerns regarding the new method.  An additional piece of hardware is now involved that costs money and has to be maintained.  Users are inconvenienced and challenged by the new technology.  There are also additional privacy concerns surrounding 2FA.  Let’s take a closer look at some of the complaints and issues that people are seeing and discussing.  Refer to the links below for details.

Some users are concerned with the physical limitations required for successful 2FA.  What if something were to happen to my cell phone?  Cell phones can be stolen, their batteries can die or we just might be in a location that prevents a signal from reaching the phone.  You might say that you can carry a printed OTP to counter any problems with receiving an OTP to your cell phone… but some users worry about running out of printed OTPs and still being stuck not able to login.  Still other users are very security conscious and don’t like carrying around printed OTPs for fear of them being stolen.  Yes, using 2FA does require increased responsibility on the part of the end user.

The increased security around 2FA brings with it increased inconvenience for some end users.  One user complained that they regularly delete browser cookies and because of that, they have to login with an OTP to their phone every time.  Others have commented that every time they launch an application, they have to go to a special web page to get a new OTP.  Some people have gone so far as to stop using 2FA all together because of the wait time for an OTP to their device.  A cell phone has been reported to be “messed up” because the user was forced to set “program specific” passwords for 10 different applications.  In addition to increased responsibility, utilizing 2FA can also be seen as a hindrance to productivity.

Some forms of 2FA have been reported to have a phone enrollment process that is too difficult for the experience level of certain users.  These people want the increased security of 2FA, but are not willing or able to come to terms with the complexity of enrolling their cell phone.  Not only the complexity, but also the privacy intrusion of giving out your cell phone number over the internet to complete the enrollment process is enough to turn 2FA candidates off.

From a company’s point of view, the increased expense of providing everyone with 2FA can be a deterrent.  More expensive cell phones will be needed and everyone will have to have an expensive SMS Messaging plan.  Even if the company were to go with OTP hardware or token keys, there are still the upfront and maintenance expense required for the necessary hardware.

Almost all of the complaints cited above revolve around the need for a separate piece of hardware to accomplish Two Factor Authentication.  Perhaps 2FA would be more appreciated and widely used if the delivery and use of the OTP can be automated to eliminate all of the negativity.  All users already have a laptop and are quite familiar with how to use it.  How about software between the client and server that can establish a secure mechanism to automatically generate and use an OTP simply because the user is at their PC and knows their password.  Knowing the password would not be enough, the user would also be required to have that PC which would satisfy the 2FA definition of “something you know and something you have”.

Finally, even though the users had negative experiences to discuss… in the end, the majority of them report that the increased security makes it worth the trouble and will continue to use 2FA.

Research Links:

China Using CyberAttacks

China has a cyber warfare program which is targeting the United States. This is a new realm of attack and how do we respond? For example as the video states, if China was flying Chinese planes over our airspace it would been seen as an act of war. So what are cyber attacks considered? Should these be seen as acts of war? Overall the government is trying to decide what the attacks are, where they are coming from, and what our offensive response will be. It seems that our government is struggling to know what to do with cyber warfare.

In another article China’s military denies any allegations that they are participating in these cyber attacks. Mandiant reported on major claims that hacking activities could be linked directly to the Chinese military. Although the military denies it these attacks have been traced back to an area in Shanghai which is run by the People’s Liberation Army. The Chinese are resting heavily on the fact that Mandiant’s discovery is based IP addresses which can easily be spoofed. Read More…


The PortalGuard software is an authentication platform which is focused on enhancing usability, while maintaining a balance between security, auditing, and compliance for your web and desktop authentication requirements. PortalGuard provides capabilities including multi-factor authentication, transparent user authentication,  self-service password management, two-factor authentication, password synchronization and single sign-on which can be seamlessly configured by user, group, or application.

Subscribe to our newsletter:

Optimizing Passwords Could be Enough

With all of this discussion around two-factor authentication there are definitely mixed opinions, as discussed in one of our previous blog postings “Are You For or Against Two-factor Authentication?”. To require two-factor authentication you typically have been attacked or are being forced to implement stronger authentication because of compliance standards. For the majority of organizations this is not the case and many take a “it is not going to happen to us” attitude. Those who are against this form of stronger security usually put up barriers because it is too difficult to implement and get widespread user adoption. With that said, I’d like to pose the question, could optimizing passwords be enough?

One IT security consultant said that two-factor authentication is like a really fancy lock on a gate to a  waist high fence, if your passwords are not optimized. Although passwords are low on usability they are still the foundation to the way we implement IT security today. So how can passwords be enough? How can you optimize them?

Really it is with best practices that you can enhance the authentication you have in place. For example, you can start by implementing stronger password strength. I know, this usually causes decreased usability, but the solution would be to implement a password strength meter at the same time so that users can see when they have met policy requirements. Then what? Well just by implementing a strikeout limit on accounts deters brute-force and dictionary attacks. If the user attempts to log in too many times the account is locked out and they must wait before attempting again. Even further, to increase security, would be to implement a more frequent password expiration policy. Too often organizations have passwords in place which never expire. This allows a hacker to obtain the password and have access to the account for an indefinite amount of time or until the user manually changes it. And so on…

Of course you are probably thinking at this point…the password is now completely unusable for your end-users. However, there are features you can put in place such as self-service password reset, recovery and account unlock to increase usability. The final step would be the “holy grail” of usability, single sign-on. By increasing the strength of the password it can be used to login once and gain access to all the user’s applications, having them only be required to remember one strong password instead of multiple ones. They are more likely to use best practices if there is only one to remember.

So as some experts say…focusing on your “one-factor” of authentication may just be enough to protect your organization and it’s sensitive data. What do you think? Is it enough for your organization?


The PortalGuard software is an authentication platform which is focused on enhancing usability, while maintaining a balance between security, auditing, and compliance for your web and desktop authentication requirements. PortalGuard provides capabilities including multi-factor authentication, transparent user authentication,  self-service password management, two-factor authentication, password synchronization and single sign-on which can be seamlessly configured by user, group, or application.

Subscribe to our newsletter:

Upon Closer Inspection: Active Directory Password Quality Rules

Despite the increasing prevalence of two factor authentication, user passwords are part of our present reality and will be part of the future for years to come.  They’re too simple and too cheap to be completely eliminated.  Indeed, the concepts of “user authentication” and “password” are inseparable for some admins much less your garden-variety operating systems and directories.

What about Identity Federation, you ask?  What about all the “non-password” based protocols like Kerberos, NTLM, OpenID, SAML, et al?  Regardless of the wrappings, the user still needs to have logged into an identity provider at some point.  In your Windows environment, Kerberos and NTLM only work well after you’ve logged into your Windows workstation… using at least a username and password.  OpenID and SAML still require an identity provider to be trusted, but that IdP only trusts the end user after they’ve authenticated to it (say it with me)… using at least a username and password.

The subtle side effect of identity federation is that it unavoidably leads to directory consolidation.  Consolidation puts more responsibility on your primary directory.  This is true whether it be Active Directory, Yahoo, or Facebook.  The more your primary directory is trusted by others, the more trustworthy it in turn must be.

So we’ve established that users still must know and maintain a password for your directory.  Maintenance should include periodic changes due to expiration.  As part of expiration, the user’s new password is then subject to password quality rules.  Take a look at Active Directory password quality rules through the years:

  • 2000– First year of Active Directory.  A single, global policy can apply the following password quality rules to all users:
    • Password history
    • Minimum password length
    • Microsoft’s proprietary complexity designation (link)
  • 2003– A single, global policy can apply the following password quality rules to all users:
    • Password history
    • Minimum password length
    • Microsoft’s proprietary complexity designation
  • 2008 – Finally, a change!  Fine-grained password policies allow multiple policies to exist within a single AD domain (link).  Now multiple policies can apply the following password quality rules to all users:
    • Password history
    • Minimum password length
    • Microsoft’s proprietary complexity designation
  • 2012 – The latest incarnation of Active Directory and you can now set Fine-grained password policies using a GUI instead of PowerShell (link).  Sweet!  Now you can “point and click” your way through the following password quality rules:
    • Password history
    • Minimum password length
    • Microsoft’s proprietary complexity designation

Ok, I think the pattern above is self-evident.  Effectively there have been no changes in password quality rules in Active Directory in over 13 years.  That’s a bit of a head scratcher.  Isn’t it amazing that the de facto directory in the world got password quality rules exactly correct on their first pass!  Well, of course I’m being facetious, but you would think some evolution would’ve occurred in this area during that time.

As a “for instance”, when AD is your primary repository, you *may* want to synchronize secondary account passwords with it.  There also *may* be systems that impose rules like a maximum password length or a smaller subset of allowable “symbol” characters (the default Password Level 0 on IBM’s iSeries fits the bill).  Since maximum length and allowable character sets are not available in AD, password synchronization cannot be reliably performed.  What gives?  And allowing myself to dream, it would also be nice if the concept of passphrases were better promoted by Microsoft which result in much stronger and easier to remember credentials.  But I may as well be discussing the possibility of shrinking the moon and keeping it for myself.

Before we get too far down on them, Microsoft does offer the Password Filter API (link) with which you can enforce your own custom password quality checks.  Forget for the moment that this C++ API does not allow you to return custom rejection messages to client workstations nor does it allow managed .NET code (which is orders of magnitude easier to develop and troubleshoot).  To handle password changes for domain accounts, these custom password filters:

  1. Must be installed on all your Domain Controllers (DC) (link)
  2. Will run within the Local Security Authority in the lsass.exe process.  The LSA runs under the Local System context and is the highest privileged subsystem on your Windows machine.  It’s effectively the NSA, CIA, MI-6, Mossad and FSB rolled into one.

Hearing this, it’s understandable if the back of your neck is getting hot and your eyelid twitch has returned.  Running anything on a DC is naturally a highly sensitive endeavor as we are all taught to fanatically protect our DCs as a mother bear protects her cubs.  If a hacker is able to get access to a DC, they could copy the SAM database offsite and directly attack the hashes therein to crack the passwords with alarming ease (link).  So it’s understandable that password filters remain a daunting option but they are an option nonetheless.

For the record, I am not a Microsoft basher nor am I a Microsoft apologist.  They have contributed huge advancements in countless technological fields.  But upon closer inspection, their password quality rules cannot be included in that endorsement despite having had many years and numerous major releases in which rectify it.  As the leader in the directory space, I don’t think it’s outlandish to expect more leadership.  But don’t fret – 2015 is only a few short years away!  I hope by then the points raised here are addressed in the next Windows Server release and this article can accumulate and settle into the digital dust of the internet.

Why do People Turn a Blind Eye to IT Security?


Even with all the news and hype surrounding corporate breaches… despite the many alternatives and discussions on the topic… with the rising demand of keeping our valuables and data secure… why are some people still putting a blind eye to security?  There are many factors that come into play for the answer to this question, here are just a few:

  1. We don’t have to worry about security.
  2. I have more pressing priorities.
  3. Security is too difficult to implement/use.
  4. We don’t have enough in our budget to afford security.

Is it simply a case of out of sight, out of mind; if it’s not broke, don’t fix it?  Why do I need security?  What would anyone want to do with my data anyway?  That’s a good question and instead of brushing it off as a fact, let’s take a closer look at what might happen if someone were to access your “undesirable” data.  Say you are a local car dealer and a competing dealer from the neighboring town gets access to some of your data.  If it is your customer list, they could use it to try and lure them away from you by marketing directly to them.   Your pricing in the hands of your competition all of a sudden gives them an edge in your pricing war.  What if the special pricing that your vendors give you were made available to your competition?  Would they use that data to also get the same or better pricing from the same vendor?  This would also help them to compete with pricing.  Before submitting to not needing to keep your data secure, think of what you might be able to do should you get the same data from your competition.

Many people know that security risks exist, but being that they are not experiencing actual damage, they are apt to be satisfied with putting security on the list, but lower in priority.  Does it really take a first attack to make security a priority?  Sure, it’s like the lottery, you can play all you want, but you are more than likely not going to win.  This is not an accurate comparison.  You definitely have a higher probability of being hacked than you do of winning the lottery.   To win the lottery all you need is luck.  To be hacked, there is no luck involved.  You simply need someone that wants to and has the means to hack your business.  Maybe you will be “lucky” enough to witness someone you know experience a security breach and this will be the reality check needed to make security a priority before your data is compromised.

Still some people don’t want to take the time or trouble to use security devices at their disposal.  A High School student with their first car in a very small rural town firmly believes that they don’t need to lock their car because car theft is not a problem in their town.  Yet this same child’s parents, having experienced multiple car break-ins during their extended lifetime, believes that auto theft is possible anywhere.  Who is right?  It’s hard to say.  You can find arguments for both sides.

Child: “I have never heard of a car being stolen in our town.”

Parent: “There is always a first time for everything”.

Do all of the high school students not lock their cars?  Perhaps it is a peer pressure issue where it is not cool to have to stick your key in the door lock when getting into your vehicle.  Which raises a good point… what if the parents sprang for a remote door lock system for the teenager’s car?  Now the car can be locked with a quick press of the button and this should definitely be cool with the other kids.  This also makes it no longer a case of “I don’t need to lock my car”, but rather “now that I don’t have to go through the process of manually locking and then unlocking my car, it is easy, so I am going to do it because you are right… there is a first time for everything”.  Being offered a means of security that is easy to use makes the decision to use the security a positive one.  Perhaps if people thought of security as usable, they would be more inclined to put it in place.

Are you making excuses?  Security is too expensive for our budget.  Have you really compared all the security options available to you?  What would it cost your company if your data got into the wrong hands or if your entire network/system was brought to its knees?  Think of security as an investment instead of another budget line item.  Pay for security now to avoid costly expenses caused by one or more intrusion attacks.  If you need a major security upgrade, try to build it in pieces to avoid a major up front expense.  Some security at first is better than no security at all.

As you have read, there are many reasons to turn a blind eye to security, but doing so can be very risky and not good for business.  Neglecting the safe keeping of your data and systems can be much more expensive, time consuming  and stressful than putting the proper measures in place to secure the business you have worked so hard to build.  Hopefully this article will encourage you to take a closer look at your security needs and how you can achieve them.

Are You for or Against Two-factor Authentication? – Download to Find Out

download self-service password resetWith recent research into how you and the general industry views two-factor authentication it is amazing to see the lack of confidence in one solution to stand above the rest. It seems that all the solutions in the market have one downside or another which is difficult for organizations to justify. This seems to be one of the main reasons keeping you from implementing it. In our related blog post “Are You for or Against Two-factor Authentication?” vendors and consultants weighed in on the subject with no clear answer being given. How are you supposed to invest in a solution which does not have 100% confidence behind it?

Well we’d like to at least take a look at what PortalGuard has to offer. The download we are offering allows you to try out the various methods PortalGuard has to offer allowing you to easily implement choices when it comes to how you will present two-factor authentication to your users. However, beyond the download PortalGuard’s PassiveKey solves the main problem two-factor has and becomes an excellent two-factor alternative which is 100% transparent to the user. For more information please download the demo and visit the website to see how it works:

Two-factor Download:

Two-factor Alternative:

Diving Into Two-factor Authentication – Simple and Complex

With the rise in need for cyber security in a world where our long-reliable password prompt is finally showing its age, the terms of two-factor, and multi-factor authentication as the next-generation alternatives are being tossed around quite a lot.  Unsurprisingly, following the popularization of the concept has been a fair amount of misuse and misunderstanding of the term; which is largely due to a lack of standardization for mechanisms of authentication.  Here we will take a look at exactly what it means for an authentication to be two-factor, what it doesn’t mean, and how many solutions that claim to be two-factor are indeed not alike, especially when it comes to their purported level of security.

What exactly does it mean for an authentication to require two or more factors to grant access? We’re all very familiar with single-factor authentication, in the form of that looming simple password prompt that can be found protecting just about any service or website login we use today.  A progressive few have taken the step towards enabling two factors for their logins: Google, Microsoft, PayPal, and Amazon Web Services, who have all provided the option of enabling a requirement for a second factor, beyond that first factor of a simple password, for those equally progressive users desiring greater security protecting their accounts.  How these additional factors take form varies per implementation, and so the general definition of having multiple-factor authentication is simply having more than the usual one-factor password requirement involved in the authentication.  What sorts of methods these factors should use to prove identity is easily disputed; however fortunately there are at least some ground-rules when it comes to what forms are valid factors of authentication and which are not.

What are valid factors?

In September of 2001, the Federal Financial Institutions Examination Council (FFIEC) had published a set of guidelines on the topic of multi-factor authentication after having witnessed a variety of vendors incorrectly citing their logins to be two, or multi-factor enabled titled “Authentication in an Internet Banking Environment” – with the emphasis on Banking institutions due to the unprecedented need for security in those environments.  The purpose of the paper was to clear up confusion regarding these terms and lay a foundation of criteria against which authentication mechanisms can be classified as involving multiple factors or not.  Criteria splits valid authentication factor methodologies into three fundamental categories:

– Something the user knows

This is the category that the simple ‘password’ exists in.  It is comprised of information the user, and the user alone, has knowledge of such as usernames and passwords, PINs, or patterns to be input.  These are the most common form of single-factor authentication methods, and are often the first factor in multi-factor solutions.

– Something the user has

Specified here are factors that the user and only the user are in possession of.  A basic example of this is your ATM card, which is required to be in your possession in order to complete transactions at ATM machines.  Notably, the PIN/Card combination required for these transactions makes ATM authentication two-factor.  This category has a very wide variety of possibilities with varying pros and cons that I will touch upon later; from connected/disconnected physical tokens, smartcards, software tokens and mobile phones.

– Something the user is

These factors involve serving a unique characteristic of yours in order to prove identity.  A common example of this is fingerprint or other biometric characteristic scanning.  A device scans the characteristic, extracts critical information from it, and stores the result in string or mathematical form.  Biometric authentication is generally less developed than the other two categories due to the expenses involved in having sensors and other equipment to do the reading.  Eye retinas are another common feature scanned for biometric authentication, though in essence, any trait that is both consistent and unique to an individual is viable for this option.

What are not valid factors?

In August of 2006, the FFIEC had then published a supplement FAQ to their original, which clarified their position even more firmly by stating that “By definition true multifactor authentication requires the use of solutions from two or more of the three categories of factors.  Using multiple solutions from the same category …would not constitute multifactor authentication”.  This effectively constrains true multi-factor authentication to involve at least one factor from each category, denying those solutions that involve say, two factors based on ‘something the user knows’, from being considered true multifactor security.  The most noteworthy example of this is approaches that involve a password for the first factor, followed by a set of challenge/answer questions for the second.  Both requirements involve something the user knows, and nothing they have or are, failing to constitute as multi-factor.  In the same document, it is also stated that login IDs, usernames, or other similar credentials are not considered true factors, due to the fact that they are not secret.

What are the best factors?

In June of 2011 the FFIEC published yet another supplement which addresses the effectiveness of controls found in layered security programs, multifactor authentication being one such layer.  It reiterates that layered security approaches “substantially strengthen the overall security of Internet-based services…” and then provides some detail discerning the effectiveness of certain authentication techniques.  Specifically it refers to additional factors of authentication that fall under the second category of ‘something the user has’, and even more specifically, software that implements device identification techniques for that factor – whereupon the device itself becomes a factor of authentication.

As mentioned earlier, methods of authentication in this category have a wide range of forms, from physical devices, cards or tokens one physically carries with them, to software based tokens, such as the ‘thumbprint’ device identification techniques generate that represents the device you are using.  Whereas these types of tokens are more criticized for their security, based on the ease of impersonating or duplicating a software token as compared to a physical, out-of-band device or token, the supplement document elaborates on effective ways to remove these risks.

It first draws a distinction between what they refer to as “Simple” or “Complex” device identification techniques.  A simple technique involves a cookie on a user’s machine that is generated by including characteristics of the machine such as geo-location or IP address, which serves as the soft token in the authentication.  A complex approach first uses more advanced ‘time based’ or ‘one-time’ cookies, to disallow use of the soft token outside of a small time frame in case it is somehow compromised.  In addition, the ‘thumbprint’ of complex device identification looks at a number of characteristics to form it, including PC configuration, time of day, IP address, geo-location, among others;  the more characteristics that are taken into account, the greater the difficulty in impersonating the token.

An additional thing to consider with multi-factor approaches that involve out-of-band solutions the user has, such as email links, Mobile phone one-time-passwords (OTP), or other devices separate the authenticating software is their being unsecure in their own communications.  In a two-factor authentication involving data being sent to a device, such as a mobile phone receiving an SMS text message with an OTP, if the devices own security is poor, that secret can be intercepted and reused.  It is important to note that these multi-factor approaches require all devices involved to apply the proper data obscuring techniques in addition to the web based login itself.

Finally, it must be said that, similar to the above point, any factor of authentication is only as good as its inherent security.  Passwords must be complex enough to warrant off brute force attacks, as well as OTP values or strings or mathematical constructs that represent the thumbprint of device identification or contextual data must have an appropriate level of entropy so that they are non-reproducible or easily decipherable.  Storage of these values must also be obscured.  In the case of physical tokens, the token must be able to be disabled in the case of it being lost and potentially used by an illegitimate party.  Possibly most importantly, any approach and its weaknesses are nicely and effectively complemented and strengthened with additional factors of authentication, and additional layers within that factor; the best interest at this point, is simply usability.

Are You for or Against Two-factor Authentication?

Looking into the two-factor authentication market as a vendor has been eye opening as to the conflicting opinions which are out there today. When posting in LinkedIn groups about the subject there are multiple responses which all go against each other, usually causing some heated debates on what is the best practice, and even more important…is two-factor even needed? Just off of one of our more popular posts we have established an interesting overview of how us, IT Security vendors and consultants feel about the subject.

Those who are all for implementing two-factor authentication really feel that it is the bare minimum with the types of attacks which are out there today. Overall implementing two-factor will absolutely improve security even though it may cause disruption to your environment, and proves to be the way to defend against complex attacks such as man-in-the-middle and keystroke loggers.

Of course the question comes up…why aren’t all organizations implementing two-factor in this case? Many companies have the “it will not happen to us” attitude and don’t feel the everyday threats that are present. IT security professionals also don’t want to “rock the boat” at their organizations if they really don’t have a 100% sure-fire way to solve the authentication challenges that go along with implementing two-factor authentication.

Finally there are the naysayers. Many advocate that companies would be fine if they just focused on securing their single factor and really focused on risk assessments and getting the maximum benefit out of passwords. Of course this method has proven with the advanced attacks to be somewhat flawed.

So where do you stand? Are you one who is all for the two-factor authentication movement and implementing it tomorrow? Or are you reserved with reasons as why it is not possible? Or are you truly a believer that password-based authentication is enough?


The PortalGuard software is an authentication platform which is focused on enhancing usability, while maintaining a balance between security, auditing, and compliance for your web and desktop authentication requirements. PortalGuard provides capabilities including multi-factor authentication, transparent user authentication,  self-service password management, two-factor authentication, password synchronization and single sign-on which can be seamlessly configured by user, group, or application.

Subscribe to our newsletter:

Enhancing SharePoint 2010 Authentication

You may already know that a Microsoft SharePoint 2010 Website can be configured for a number of authentication types:

  1. Windows Authentication (NTLM, Kerberos, Anonymous, Basic and Digest)
  2. Forms-based authentication (LDAP, SQL and Custom membership and role providers).

But what do you do if you want stronger authentication for your SharePoint site or maybe provide your SP users with Self-Service Password Management (SSPM). The good news is that SharePoint 2010 can also be configured for Claims Based (or SAML Token) authentication which expands the options available to include the options provided by the authentication mechanism used by the SAML Identity Provider (IdP) submitting the claims. Claims-based authentication allows for a website or application to request a SAML token from a third party IdP. The IdP now has the responsibility of authenticating the user before generating and returning the SAML token. This allows the additional authentication features of the IdP to be shared by the SharePoint web site.

Let’s say you are interested in providing Two Factor Authentication (2FA) for your SharePoint users as well as allowing them SSPM. Let’s also say that you have a SAML IdP that uses a proprietary authentication service which provides 2FA and SSPM to the user’s in the repository. The trick now is to allow SharePoint to take advantage of the IdP’s features.

SharePoint 2010 can be integrated with a third party IdP to request a SAML token for the authentication of a website user. Configuration changes must take place on the SharePoint side as well as the IdP. The SharePoint web site is configured to use the SAML protocol to send a SAML request to the IdP. On the IdP, a Relying Party Trust for the SharePoint site must be created/specified. In addition to identifying the SharePoint web site in the Relying Party, claims (attributes about the user) are also specified. These claims are sent to the SP site within the SAML token. The SAML token lets the site know that the user is authenticated and the claims are used by the site to determine whether or not that user has access to the requested website resource. Don’t forget, a user can be authenticated, but still not have access to all of the resources on the site.

This is all great you say, but I was promised 2FA and SSPM for my users. Where do these features fit into the integration? Well, remember that the IdP has to first authenticate the user before it will generate and deliver the SAML token. The IdP is employing a third party authentication appliance that supports the 2FA and SSPM while the user is authenticating.

So, whether you have an IdP in place or not, configuring SharePoint to authenticate with features not natively provided by SharePoint can be achieved without too much trouble. Either put an IdP in place or use your existing IdP to enhance the security and usability of your SharePoint user’s experience.