So what is SSO and why do I care?
SSO is an acronym for “Single Sign-On”. There are various forms of single sign-on with the most common being Enterprise Single Sign-On (ESSO) and Web Single Sign-On (WSSO).
Each method utilizes different technologies to reduce the number of times a user has to enter their username/password in order to gain access to protected resources.
Note: There are various offshoots from WSSO implementations – most notably utilizing proxies or portal servers to act as a central point of authentication and authorization.
Enterprise Single Sign-On
In ESSO deployments, software typically resides on the user’s desktop; the desktop is most commonly Microsoft. The software detects when a user launches an application that contains the username and password fields. The software “grabs” a previously saved username/password from either a local file or remote storage (i.e. a special entry in Active Directory), enters these values into the username and password fields on behalf of the application, and submits the form on behalf of the user. This process is followed for every new application that is launched that contains a username and password field. It can be used for fat clients (i.e. Microsoft Outlook), thin clients (i.e. Citrix), or Web-based applications (i.e. Web Forms) and in most cases the applications themselves are not even aware that the organization has implemented an ESSO solution. There are definite advantages to implementing an ESSO solution in terms of flexibility. The drawback to ESSO solutions, however, is that software needs to be distributed, installed, and maintained on each desktop where applications are launched. Additionally, because the software resides on the desktop, there is no central location in which to determine if the user is allowed access to the application (authorization or AuthZ). As such, each application must maintain its own set of security policies.
The following diagram provides an overview of the steps performed in ESSO environments.
A user launches an application on their desktop. An agent running in the background detects a login screen from a previously defined template. If this is the first time the user has attempted to access this application, they are prompted to provide their credentials. Once a successful login has been performed, the credentials are stored in a credentials database. This database can be a locally encrypted database or a remote server (such as Active Directory). Subsequent login attempts do not prompt the user for their credentials. Instead, the data is simply retrieved from the credentials database and submitted on behalf of the user.
Container-Based Single Sign-On
Session information (such as authenticated credentials) can be shared between Web applications deployed to the same application server. This is single sign-on in its most basic and limited fashion as it can only be used across applications in the same container.
The following diagram provides a high level overview of the steps performed in container-based single sign-on environments.
A user accesses a Web application through a standard Web browser. They are prompted for their credentials which can be basic (such as username and password) or can utilize other forms of authentication (such as multi-factor, X.509 certificates, or biometric). Once the user has authenticated to the application server, they are able to access other applications installed in the same J2EE container without having to re-authenticate (that is, if the other applications have been configured to permit this).
Traditional Web Single Sign-On
In contrast, WSSO deployments only apply to the Web environment and Web-based applications. They do not work with fat clients or thin clients. Software is not installed on the user’s desktop, but instead resides centrally within the Web container or J2EE container of the Web application being protected. The software is often times called a “policy agent” and its purpose is to manage both authentication and authorization tasks.
The following diagram provides a high level overview of traditional Web Single Sign-On.
A user first attempts to access a Web resource (such as ADP) through a Web browser. They are not authenticated to the domain so they are directed to the central authentication server where they provide their credentials. Once validated, they receive a cookie indicating that they are authenticated to the domain. They are then redirected back to the original Web resource where they present the cookie. The Web resource consults the authentication server to determine if the cookie is valid and that the session is still active. They also determine if this user is allowed access to the Web resource. If so, they are granted access. If the user were to attempt to access another Web resource in the same domain (i.e. Oracle eBusiness Suite), they would present the cookie as proof that they are authenticated to the domain. The Web resource consults the authentication server to determine the validity of the cookie, session, and access rights. This process continues for any server in the domain that is protected by WSSO.
Portal or Proxy-Based Single Sign-On
Portal and proxy-based single sign-on solutions are similar to Standard Web Single Sign-On except that all traffic is directed through the central server.
Portal Based Single Sign-On
Target-based policy agents can be avoided by using Portal Servers such as LifeRay or SharePoint. In such cases the policy agent is installed in the Portal Server. In turn, the Portal Server acts as a proxy for the target applications and may use technologies such as SAML or auto-form submission. Portal Servers may be customized to dynamically provide access to target systems based on various factors. This includes the user’s role or group, originating IP address, time of day, etc. Portal-based single sign-on (PSSO) serves as the foundation for most vendors who are providing cloud-based WSSO products. When implementing PSSO solutions, direct access to target systems is still permitted. This allows users to bypass the Portal but in so doing, they need to remember their application specific credentials. You can disallow direct access by creating container-specific rules that only allow traffic from the Portal to the application.
Single Sign-On Involving Proxy Servers
Proxy servers are similar to PSSO implementations in that they provide a central point of access. They differ, however, in that they do not provide a graphical user interface. Instead, users are directed to the proxy through various methods (i.e. DNS, load balancers, Portal Servers, etc.). Policy agents are installed in the proxy environment (which may be an appliance) and users are granted or denied access to target resources based on whether they have the appropriate credentials and permission for the target resource.
The following diagram provides a high level overview of centralized single sign-on using Portal or Proxy Servers.
Federation is designed to enable Single Sign-On and Single Logout between trusted partners across a heterogeneous environment (i.e. different domains). Companies that wish to offer services to their customers or employees enter into a federated agreement with trusted partners who in turn provide the services themselves. Federation enables this partnership by defining a set of open protocols that are used between partners to communicate identity information within a Circle of Trust. Protocols include SAML, Liberty ID-FF, and WS-Federation.
Implementation of federated environments requires coordination between each of its members. Companies have roles to play as some entities act as identity providers (IDP – where users authenticate and credentials are verified) and service providers (SP – where the content and/or service originate). Similar to standard Web Single Sign-On, an unauthenticated user attempting to access content on a SP is redirected to an appropriate IDP where their identity is verified. Once the user has successfully authenticated, the IDP creates an XML document called an assertion in which it asserts certain information about the user. The assertion can contain any information that the IDP wishes to share with the SP, but is typically limited to the context of the authentication. Assertions are presented to SPs but are not taken at face value. The manner in which assertions are validated vary between the type of federation being employed and may range from dereferencing artifacts (which are similar to cookies) or by verifying digital signatures associated with an IDP’s signed assertion.
The interaction between the entities involved in a federated environment (user, SP and IDP) is similar to the Web Single Sign-On environment except that authentication is permitted across different domains.
A major difference between federated and WSSO environments involves the type of information generated by the authenticating entity to vouch for the user and how it is determined that that vouch is valid and had not been altered in any way.
The following table provides a feature comparison between Web SSO and Enterprise SSO.
|Features||WSSO / PSSO / Proxy||ESSO|
|Applications Supported:||Web Only||Web Applications and Fat Clients|
|“Agent” Location:||Target System||User Desktop|
|Technologies:||SAML, Form Submission, Cookies||Form Submission|
|Internal Users?||Yes||Yes (through portal)|
|Central Session Logoff?||Yes||No|
|Global Account Deactivation?||Yes (through password change)||No|
By now, many of you have already heard about the hacking of Alaska Governor Sarah Palin’s Yahoo e-mail account earlier this week (on or about Tuesday 9/16/2008). If not, here is a brief synopsys of the story.
Sarah Palin’s personal Yahoo e-mail account was compromised and the contents of her account (including her address book, inbox and several family photos) were posted to the Internet.
Someone with the e-mail address of email@example.com posted a message on the Web site 4chan about how he used Yahoo! Mail’s password-recovery tool to change the Alaska governor’s password and gain full access to her e-mail account.
“i am the lurker who did it, and i would like to tell the story,” firstname.lastname@example.org wrote.
(I have included the full text at the bottom of the post for those interested. Be forewarned that some of the language is NOT family friendly.)
The email@example.com e-mail account has been linked to 20-year old David Kernell; son of democratic Tennessee State Representative, Mike Kernell, and a student at the University of Tennessee-Knoxville. While David has not been included in any official investigation as of yet, his father, has confirmed that the person being the subject of the many blog posts and news articles around the Internet is indeed his son.
So how did the alleged hacker do it?
First of all, he had to identify Sarah Palin’s email address to be firstname.lastname@example.org. A recent article in The Washington Post indicated that Sarah Palin was using a personal e-mail address of email@example.com to conduct government business. But that was not the e-mail account that got hacked. So how do you get from firstname.lastname@example.org to email@example.com?
Allahpundit posted an article on hotair.com that presents some interesting ideas about how the hacker might have arrived at the firstname.lastname@example.org account, but for the time being — and void of any conspiracy theories — let’s just assume he figured it out.
Now that he had the e-mail address, how was he able to gain access to the account?
The hacker claims to have used Yahoo! Mail”s password-recovery tool to reset the password. To do this, you simply go to Yahoo! Mail and click on the Forget your ID or password link.
This takes you to a page where you enter your Yahoo! ID. In the case of Sarah Palin’s account, this would be “gov.palin”.
To reset your password with Yahoo! Mail, you can either have it sent to your secondary email address or you can indicate that you no longer have access to this account.
(As a side note, I do not particularly like the fact that Yahoo! shows even a portion of my secondary email account in the email address HINT. But that is another story. )
Selecting the “I can’t access my alternate email address” radio button allows you to answer questions to challenge questions as follows:
These are generic authentication questions, but in the case of Sarah Palin, the hacker had to answer one additional question that had to do with where she met her husband. The hacker guessed that Alaska’s governor had met her husband in high school, and knew the Republican vice presidential candidate’s date of birth and home Zip code, the Associated Press reported. Using those details, the hacker was able to successfully access Palin’s email account where he was able to assign a new password of “popcorn”.
The rest is simply news.
So what does the hacking of Sarah Palin’s email account tell us about security and Identity Management in general?
One of the big benefits of an Identity Management solution is that it provides end-users with a way to update their own data and reset their own passwords. This is a HUGE cost reduction for companies as it reduces the number of calls to the Help Desk. But just like everything else, there has to be a careful balance between security and convenience.
Authentication questions provide a means for users to gain access to their accounts when they have forgotten their passwords. This is the mechanism that Yahoo! Mail uses and has been adopted by many Identity Management solutions. Authentication questions are extremely convenient for companies that have password policies that are so stringent that their users cannot remember their passwords. They also come in handy after three-day holiday weekends as the day that employees return to work typically generates numerous calls to the Help Desk for password reset.
While authentication questions are convenient and produce a cost savings, a company does, however, need to take care when providing this solution. Who decides what the questions are and what happens if the end-user does not have an answer for a particular question? These are some of the issues that need to be considered. I have seen questions all over the board. Below are some of the ones that I find particularly insecure since many of them can be answered by Google searches or social engineering. In some cases, the questions cannot be answered with one answer and some cannot be answered at all.
Questions that can be answered by social engineering or search:
· What is your mother’s maiden name?
· In what city where you born?
· In what year where you born?
· What was your first school?
· What was your first phone number?
Questions that might not be answered at all:
· Who is your favorite superhero?
· What is your pet’s name?
· What is your library card number?
· What was your first teacher’s name?
· What is the air speed velocity of a coconut-laden swallow?
If you force a user to provide answers that are easily obtainable, then your risk is drastically increased (just ask Sarah Palin). If you force users to answer questions that are difficult (or impossible) to answer, then then your risk is also increased as the user may just provide a common answer to all questions (i.e. “blue”). So either way you go, it can be a difficult decision to make.
I have found that one of the best mechanisms is a an approach that allows the end user to define their own set of authentication questions while the company provides a sample set of common (yet hopefully secure) questions as well. This allows the company to have certain control, but also allows the user the ability to provide questions and answers using information that only they know. Now, I know that some may argue that users typically pick the path of least resistance and that many of them will pick easy questions (and therefore have easy answers) but by combining a set of the company-specific questions in addition to those supplied by the user the company can bridge the gap between security and convenience.
By the way, if you use an application that allows you to provide your own authentication questions, then I STRONGLY suggest that you go and provide your own security question(s) to one(s) that have meaning and applicability to you.
Here is the synopsis of what rubico said at 4chan:
rubico 09/17/08(Wed)12:57:22 No.85782652
Hello, /b/ as many of you might already know, last night sarah palin’s yahoo was “hacked” and caps were posted on /b/, i am the lurker who did it, and i would like to tell the story.
In the past couple days news had come to light about palin using a yahoo mail account, it was in news stories and such, a thread was started full of newfags trying to do something that would not get this off the ground, for the next 2 hours the acct was locked from password recovery presumably from all this bulls**t spamming.
after the password recovery was reenabled, it took seriously 45 mins on wikipedia and google to find the info, Birthday? 15 seconds on wikipedia, zip code?
well she had always been from wasilla, and it only has 2 zip codes (thanks online postal service!)
the second was somewhat harder, the question was “where did you meet your spouse?” did some research, and apparently she had eloped with mister palin after college, if youll look on some of the screensh**s that I took and other fellow anon have so graciously put on photobucket you will see the google search for “palin eloped” or some such in one of the tabs.
I found out later though more research that they met at high school, so I did variations of that, high, high school, eventually hit on “Wasilla high” I promptly changed the password to popcorn and took a cold shower…
>> rubico 09/17/08(Wed)12:58:04 No.85782727
this is all verifiable if some anal /b/tard wants to think Im a troll, and there isn’t any hard proof to the contrary, but anyone who had followed the thread from the beginning to the 404 will know I probably am not, the picture I posted this topic with is the same one as the original thread.
I read though the emails… ALL OF THEM… before I posted, and what I concluded was anticlimactic, there was nothing there, nothing incriminating, nothing that would derail her campaign as I had hoped, all I saw was personal stuff, some clerical stuff from when she was governor…. And pictures of her family
I then started a topic on /b/, peeps asked for pics or gtfo and I obliged, then it started to get big
Earlier it was just some prank to me, I really wanted to get something incriminating which I was sure there would be, just like all of you anon out there that you think there was some missed opportunity of glory, well there WAS NOTHING, I read everything, every little blackberry confirmation… all the pictures, and there was nothing, and it finally set in, THIS internet was serious business, yes I was behind a proxy, only one, if this s**t ever got to the FBI I was f****d, I panicked, i still wanted the stuff out there but I didn’t know how to rapids**t all that stuff, so I posted the pass on /b/, and then promptly deleted everything, and unplugged my internet and just sat there in a comatose state
Then the white knight f****r came along, and did it in for everyone, I trusted /b/ with that email password, I had gotten done what I could do well, then passed the torch , all to be let down by the douchebaggery, good job /b/, this is why we cant have nice things