Single Sign On (SSO) Question

When enabling single sign on is it possible to have nested user accounts so for example to log on to my machine my username is: dustyrack and password:password. Once I've logged on my file server requires additional creditals username: dustyrack1 password
: password. Using single sign on would you be able to use this nested structure or would the user need to log on using the other username? Just curious. Question which come to mind reading the security+

Find more posts tagged with

Comments

teancum144

I don't believe SSO typically works the way you describe. Most SSO implementations (within an autonomous system) are based on Kerberos, which works as follows:

Kerberos Logon:

To Authentication Server (AS), user sends clear-text message (1) to identify self (user-principal name), and (2) to request a service (service-principal name).
AS verifies user and service identity against principal database.
If identity verification succeeds, AS sends the user (1) a randomly generated session key – encrypted with the user’s password, and (2) a Ticket Granting Ticket (TGT) – encrypted with the service’s password.
If user credentials can decrypt the session key, authentication is complete.

Kerberos authentication to a service:

To Ticket Granting Server (TGS), user sends clear-text message: (1) user identity, (2) requested service’s identity, (3) service access lifetime, (4) TGT – service password encrypted, and (5) authenticator data – logon session key encrypted.
The TGS verifies data using the principal database.
If verification succeeds, TGS replies with (encrypted with session key obtained at logon) (1) Application-Service session key, (2) key lifetime timestamp, and (3) a Service Ticket – encrypted with service’s host’s encryption key.
User employs the data in 1 – 3 to authenticate to the application server and use the requested service.

paul78

You are describing something known as Federated Identity Management.

The scenario that you described is possible. It's not so much used in your specific scenario, but it's more common when federating the identities across different applications. For example, you could have a web application that you log in to use. But perhaps some discrete function is part of another autonomous application. The application developer may choose to use something like SAML so "prove" to the other autonomous application that the user is already authenticated.

Caveat - I don't really know anything about the scope of the Security+ so my post is really just an FYI because I do not know if this topic is part of the Security+ syllabus.

teancum144

paul78,
Wouldn't federated identity management (SAML, OpenID, etc.) more applicable between/among different autonomous systems? From DustyRack's question, I get the impression that the context of his question is more within a single autonomous system (Autonomous System (Internet) - Wikipedia, the free encyclopedia).

MrAgent

Dusty,
SSO uses the same username/pw for all services. Having a seperate username/pw is the exact opposite of SSO.

@paul78, I just finished a graduate class dedicated to Identity Management. You are spot on with your reply.

f0rgiv3n

There are other products out there, I believe, that claim the SSO acronym that can do this. Not just using FIdM. This product is normally an agent running on the PC that has the different sets of credentials. It's more of a "password management" product that can be trained to recognize when a specific app is requesting credentials.

The application prompting for credentials has no clue that the user did not type it in. No server-to-server federation or trusts are needed because it's all done on the client.

While it's possible, I'm not saying it's a good solution... Just stating what I know!

paul78

@teanum - I probably shouldn't have used the term "autonomous" - that link is about ASN's for BGP routing.

What I meant is discrete and separate application - each with their own identity store and authentication scheme.

So for example:

Let's say that I have AppA and AppB. Both are web-based applications written by different companies. Suppose both companies sell their product to the same customer. The customer has an internal application for all their users to log in and authenticate. What the customer can do is to ask their vendors to modify AppA and AppB to support identity federation so that the customers internal application can be used for authentication. Both AppA and AppB would still have their own identity store - but there would be a scheme to map the users back from the internal application.

One common solution is SAML. It's been a while, but there is also a very popular commercial solution that by Computer Associates called SiteMinder which was common before there was SAML.

@MrAgent - thanks.

teancum144

paul78,
Thanks for the example. Isn't SSO within one company's network(s) typically not based on FIdM, but on a single ID (e.g. Kerberos)? Conversely, isn't FIdM (multiple IDs) typically used among/between different entities' networks? The original poster seemed to ask about logging in to his workstation and then authenticating to a file server within the same entity's network. That is what I'm trying to clarify.

Darril

In response to the original poster, I'm not sure I'd call it a "nested structure" though separate accounts can be used and connected for single sign-on (SSO).

As a simple example in a Windows domain environment with a SQL server, imagine a user logs on once through Kerberos for SSO (as teancum144 describes) with an account name of DustyRack.

A SQL server administrator can create a user account on the SQL server named DR1, and then connect DR1 with DustyRack.
The user logs on with the DustyRack Kerberos account.
When the user connects to the SQL server, it recognizes the connection between DustyRack and DR1 and the user is granted privileges on the SQL server as DR1.
The SQL server does do behind-the-scenes checks with Kerberos to verify that DustyRack has authenticated, but this is transparent to the user. The user doesn't need to enter credentials more than once in this scenario.
All that said, both domain groups and SQL server roles are commonly used to group users. In other words, it isn't common to connect a single Kerberos account to a single SQL server user account.

I cannot imagine a scenario when you would this with local accounts on a file server though. Instead, users would be granted privileges on the file server based on their domain account in Kerberos rather than on a local account on the file server.

For Security+, you should be aware of homogeneous SSO systems for similar OSs and nonhomogeneous SSO systems.

For example, Kerberos is a homogeneous SSO used within a single company. It's homogenous because all computers are running a similar operating system such as Windows and users/computers authenticate via a Kerberos server such as a domain controller. A user logs on with a single account and is able to access resources with this account without needing to log on again.

A non-homogeneous environment includes computers and operating systems of any type and a federated identity management system allows users to authenticate through a federated database. Paul78's explanation of a web application is a good example. User's typically log on once (single sign-on) and then behind the scenes, the web applications are exchanging data to prove that a user is authenticated before providing access to other areas of the web application or other web applications.

If you pursue the CISSP after Security+, you'll need to know some of the details of federation identity management systems including some of the standards such as Security Assertion Markup Language (SAML), Service Provisioning Markup Language (SPML), and Extensible Access Control Markup Language (XACML). However, that level of detail is not needed for Security+.

Hope this helps.

DustyRack

Thanks everyone for your replies it helps alot.

Darril, im currently reading through your book and i mist say WOW! I cant seem to put my kindle down. One of the best technical books that i have ever bought highly recommended.

Darril

Thanks for the kind words DustyRack. I just got back from a great trip to your country, fulfilling a longtime dream of my wife's to visit Europe. We had a great time and I even had the opportunity to spend some time with Ginx TVs Adam Savage (host/presenter of Planet of the Apps).

Good luck with the exam.