4

I am studying the domain of Identity and Access Management in CISSP, and I come across the three terms Federated Identity Management (FIM), Third Party Identity Services (3PIS) and Single Sign-On (SSO). After some readings, including What is the difference between Federated Login and Single Sign On?, I believe I know the difference among the three things:

(1) SSO is an example of 3PIS
(2) But not all SSO are 3PIS, when the authentication mechanism is devised by the provider of the resource
(3) An advantage of FIM is that it can provide SSO
(4) FIM does not always provide SSO
(5) FIM may use 3PIS mechanism, if the mechanism is devised by an organization not related to any of the providers of the resource
(6) FIM may not use 3PIS mechanism, if the mechanism is devised by one of the providers of the resource

Assume the above are all true, SSO, 3PIS and FIM can all exist in the same system, but they can also be independent. So I am now looking for real-life examples for all the 7 combinations below:

(a) SSO + 3PIS + FIM --> ??
(b) SSO + 3PIS, not FIM --> Kerberos for authenticating a MS Windows domain.
(c) SSO + FIM, but not 3PIS --> Azure Active Directory for accessing Office365 and SalesForce, since Office365 and Azure are both developed by MS.
(d) SSO, but not 3PIS, not FIM --> Microsoft Active Directory for accessing MS resources.
(e) 3PIS + FIM, but not SSO --> ??
(f) 3PIS, but not SSO, not FIM --> ??
(g) FIM, but not 3PIS, not SSO --> ??

Am I right in the above 3 examples (b), (c), (d), and are there any real-life examples for the other 4 cases? Any suggestion or comment is welcome.

1

TL;DR:

FIM (or FidM) refers to an abstract concept of identity management. Organizations that have implmented a FIM system, use it to manage identities and trust of their users in order to simplify access to resources.

3PIS is a product you acquire from a vendor. It supports setting up or installing a FIM and may or may not provide a SSO functionality for users.

SSO is a mechanism put into a bit of software that allows users to access multiple services or systems with either only one login or the same login credentials.


(1) SSO is an example of 3PIS

Not exactly. A 3PIS may include a mechanism for SSO, but doesn't necessarily have to. (Although - I think - most current ones do.) You wouldn't say: "Our SSO is a 3PIS." but rather "Our 3PIS uses SSO."

(2) But not all SSO are 3PIS, when the authentication mechanism is devised by the provider of the resource

Well, yeah, kinda. You do need an FIM to use SSO, you can use a 3PIS to set up your FIM. But not all systems/services support SSO.

(3) An advantage of FIM is that it can provide SSO

Yes.

(4) FIM does not always provide SSO

I don't know any, but that doesn't mean anything.

(5) FIM may use 3PIS mechanism, if the mechanism is devised by an organization not related to any of the providers of the resource

3PIS is not a mechanism itself. Identity providers use e.g. certificate-based identification mechanisms to establish trust between users, the service provider and the organization that utilises a 3PIS.

(6) FIM may not use 3PIS mechanism, if the mechanism is devised by one of the providers of the resource

See above.


As you are still studying, maybe you want to try to answer the rest of your question for yourself. If things are still not clear, I will try to provide some more context.


Disclosure: I am neither certified with CISSP nor have I ever studied for their certificate.

  • Thanks, after some thoughts, I think that whether a service is 3PIS depends on who uses it. Just like (c) above, it's 3PIS for SalesForce, but not 3PIS for Office365 since the latter is also a MS product. I agree with you on (1), (5) and (6). For (4), according to Wikipedia (en.wikipedia.org/wiki/Single_sign-on) if "the user (needs) to enter their login credentials each time they access a different site or application", then it is not SSO. So FIM tools like OAuth and Facebook Connect are not developed with SSO in mind, but other systems using these tools may provide SSO. – GreenPenguin Jul 31 '17 at 17:42
1

I would add that 'Federated Identity Management' is a bad label. Identity Management means creating, managing and deleting identities in a repository, such as an LDAP directory. Federated "identity" management systems don't do any of those things - and should more properly be referred to as "Federated Access Management" systems.

FAM (as above) means that application A can offload the process of identifying and authorizing a user who wishes to sign in to application B. This process may also offload some authorization decisions (what the user can do in app A may be up to app B).

There are some more-or-less standard protocols for federation, including Secure Assertions Markup Language (SAML) and OAuth (I guess that stands for Open Authentication). An "also-ran" protocol is the WS-Federation set of protocols championed by Microsoft and basically nobody else (used between ADFS, SharePoint and O365 for example).

You can infer a definition for identity management from above. It may be abbreviated "IDM."

We usually don't do IDM alone. After all, most systems and most organizations only care about identity as a pre-requisite for granting access to something. In practice, we do "identity and access management" together -- i.e., manage the lifecycle of objects that represent people or nonhuman processes, and at the same time grant and revoke access rights, such as membership in security groups. The combination of identity and access management is shortened to IAM.

Some analyst firms like to focus on the governance aspect of IAM, such as reviewing what a given user has access to and revoking no-longer-appropriate entitlements. They like it so much that they sometimes refer to IAM as Identity Governance and Administration (IGA). Confused yet? It's just an acronym, refers to the same capabilities in reality.

Single sign-on is a separate but related thing. Refer back to the FAM idea above. When application B authenticates the user on behalf of application A, does it prompt the user to enter his ID and password, or whatever other credentials, every single time the user finds himself at application B's login page? After all, application B could drop a cookie in the user's browser - say good for an hour or a day, and if the user signs into app A again, or perhaps another app (say app C), which also relies on app B's login page, then app B will notice that it already and recently authenticated the user, and does not need to do so again.

This last bit - skipping the login process if an authentication process was recently completed for the same user, is single sign-on or SSO for short.

I hope that helps!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.