Which are commonly passed from the service provider to the identity in a federated solution?

Delinea Blog > Federated Identity Management vs. SSO

Which are commonly passed from the service provider to the identity in a federated solution?

Federated identity management (FIM) and single sign-on (SSO) are not synonymous— FIM gives you SSO, but SSO does not give you FIM. That minor detail is very important to understand, as you make the leap to the cloud and adopt more SaaS applications. While you will have some initial startup costs with FIM by building out an identity service provider (IDP), it is cheaper in the long run than using simple SSO with FIM.

Why is that so? Well, let’s start by understanding what the difference between the two is.

Single Sign-on (SSO) allows users to access multiple services with a single login.

The term is actually a little ambiguous. Sometimes it's used to mean that a user only has to provide credentials once per session and then gains access to multiple services without having to sign in again during that session. Think your bank account -- you log in once but now you can access all your accounts such as savings, retirement, investment, mortgage, and so on without being prompted for credentials again. But in all reality, these individual accounts are all separate from each other. If you pay close attention to your browser bar as you click on the different accounts, you’ll most likely see something like this there:

https://yourbankurl/switchaccount/SAML_Action...

Some of the downsides with SSO are that you are reliant on the SaaS application's support for Multi-Factor Authentication (MFA) for additional protection. The user has to remember all the different logins or resort to a password manager. IT has to manage all the individual SaaS logins for all employees, which results in departed employees having access to confidential information long after they have left the company because IT or the LOB has not de-provisioned / deactivated their SaaS account. It also results in the company still paying for licenses that are assigned to former employees. All of the above make SSO without FIM costly and insecure.

Now federated identity management (FIM) refers to a way to connect identity management systems together. With FIM, a user's credentials are always stored with a "home" organization (the "identity provider"). When the user logs into a service (SaaS application), instead of providing credentials to the service provider, the service provider trusts the identity provider to validate the credentials. So the user never provides credentials directly to anyone but the identity provider. You are federating your service providers (SaaS applications) with your FIM (identity provider). It’s a many-to-one mapping, many SaaS applications to one identity provider.

FIM and SSO are different but are very often used together. Remember, FIM gives you SSO, but SSO doesn’t necessarily give you FIM.

Identity federation offers economic advantages, as well as convenience, to enterprises and their subscribers. For example, multiple corporations can share a single application (B2B federation), with resultant cost savings and consolidation of resources. In order for FIM to be effective, the partners must have mutual trust. Authorization messages among partners in an FIM system can be transmitted using security assertion markup language (SAML) or a similar XML standard that allows a user to log on once for affiliated but separate websites or networks. Additionally, FIM systems (IDP’s) like Delinea provide automated account provisioning and de-provisioning into SaaS applications like Office 365, Salesforce, AWS, and ServiceNow. Automated account provisioning gives the IT department the benefit that a new user is automatically provisioned into all applications assigned to him automatically based on role or group membership in their user databases such as Active Directory or LDAP. The user has the benefit of having only to remember his “Domain Credentials.” In a nutshell, FIM is cheaper and much more secure in the long run because:

  • It doesn’t need to manage individual SaaS accounts. It happens automatically.
  • Licenses for said SaaS applications are assigned or removed automatically.
  • Access to ALL SaaS applications is removed at once.
  • The user only needs to remember ONE username and password combination.
  • FIM allows IT to protect critical apps with multi-factor authentication.
  • The User has a single user interface to access ALL his SaaS applications.

Federated Identity & Authentication

Your digital identity is made up of attributes that define you as a unique person moving through the landscape. Federated identity is an agreement between entities about the definition and use of those attributes. Agreements allow you to sign on in one place and then jump to another asset without signing in again.

Identity federation is a generic term, and it can apply to many different types of companies, platforms, and protocols. But those that offer identity federation products agree to use technology others understand and can access. That way, different platforms can communicate and share without requiring another login.

Seven so-called "laws of identity" sit beneath federated identity systems.

1. User control and consent: Users give permission to share data, and they have at least some say in how shares happen.

2. Minimal disclosure: The smallest amount of identifying information is shared, and it's stored securely and deleted quickly.

3. Justification: Only those who can prove they need access can get it.

4. Directed identity: Protection of identity is paramount, and users should be assigned private identifiers for that purpose. Companies can't work together to build a more permanent view of someone working across platforms.

5. Competition: Many identity providers should be supported, as competition breeds better performance.

6. Human integration: A real person has a place in the process, reducing the risk of computer-to-computer hacks.

7. Consistency: The users have a simple, consistent experience among platforms.

Read through these concepts carefully, and a picture of federated identity begins to form. And chances are, every modern user has encountered the process at least once. If you've logged into Google and then dashed to another website for protected info without another login, you've encountered federated identity concepts. 

How Does Federated Authentication Work?

Federated identity management relies on strong agreements. Identity providers and service providers develop an understanding of what attributes (such as your location or phone number) are representative of who you are online. Once those credentials are verified, you're authenticated across multiple platforms.

Common technologies used in federated identity management include:

  • Security Assertion Markup Language (SAML)
  • OAuth 
  • OpenID

Companies might use security tokens, such as JWT (JSON Web Token) tokens and SAML assertions, to pass permissions from one platform to another.

Consider Google's federated identity process with OAuth. To use this system, developers must:

1. Pull OAuth credentials from Google's API. Choose data, such as a client ID and client secret, that both Google and your company know.

2. Grab an access token from the Google Authorization Server. Users will need a token from Google to complete web requests for access.

3. Compare the access scopes. Users grant access to data, and you must compare that your request matches their willingness to share.

4. Send the token to an API. Users are ready to gain access, as long as the token is included in an HTTP authorization request header.

To a user, the process is almost invisible. They come to a website they'd like to enter, and they're shown a screen asking them to log in via other credentials. They hit a button or two, and access magically appears.

The Government's Role in Identity Federation

Computer developers think of themselves as autonomous entities, free of politics and interference. In reality, the government is deeply interested in how federated identity works and who is in charge of it.

That interest stems from Homeland Security Presidential Directive 12, issued in 2004. Here, experts required secure credentials to access government assets, and teams were encouraged to build systems that allowed for quick movement between platforms and programs. Speed was crucial, but safety was needed.

Since 2004, plenty of companies have developed agreements, protocols, and programs for federated identity. But more work is required.

Currently, the National Cybersecurity Center of Excellence and the National Strategy for Trusted Identities in Cyberspace National Program Office are collaborating on a Privacy-Enhanced Identity Federation project. When complete, the team will release a set of standards companies can use for federated identity. No release date is available quite yet.

Benefits of Federated Access

Some companies allow secure sign-on without touching federated identity concepts at all. Others wouldn't dream of running a product this way. Which side is right?

The benefits of federated identity include:

  • Lower cost. Use federated products, and you won't need to build your own SSO solutions.
  • Enhanced efficiency. Employees won't need to waste time logging into systems over and over again.
  • Protected data. Federated solutions come with an enhanced expectation of data protection and security. And since each login is a point of vulnerability for companies, streamlining the process could reduce hacking risks.

Misconceptions About Federated Access

There aren’t significant drawbacks to using federated access, but there are some common misconceptions about it.  These include:

  • Less control. Federated identity management solutions follow a specific set of rules and agreements. Some people fear this means less control, but this isn’t the case. SSO vendors usually provide various configuration options so systems can behave as needed.
  • Potential security risks. No authentication protocol is entirely secure, and some federated programs come with known vulnerabilities. Generally, a federated program built to typical standards is more secure than almost any other program.

Plenty of companies consumers know and trust use federated identity concepts, including Google, Microsoft, Facebook, and Yahoo. If these organizations lean on the concepts, it's realistic to assume that they're safe and trusted. But every company must do its own assessment of risk and benefit.

Discover how Okta can help you decide if federated authentication or single sign-on authentication is the more secure solution for your organization.

References

Average Business User Has 191 Passwords. (November 2017). Security.

Federated Identity Management. (2009). David W. Chadwick.

Understanding Federated Identity. (August 2007). Network World.

Using OAuth 2.0 to Access Google APIs. Google Identity Platform.

Identity Federation Governance: Catalyst for the Identity Ecosystem. (2014). Deloitte Development.

Privacy-Enhanced Identity Federation. National Institute of Standards and Technology.

Identity Federation: A Brief Introduction. (September 2018). Medium.

Federated Identity Management Challenges. Identity Management Institute.

Common Federated Identity Protocols: Open ID Connect vs. OAuth vs. SAML 2. Hack EDU.

Economic Tussles in Federated Identity Management. (October 2012). First Monday.

A Study on Threat Model for Federated Identities in Federated Identity Management System. (June 2010). 2010 International Symposium on Information Technology.

The Need for a Universal Approach to Identity Management. (July 2018). Forbes.

Federated Identity Management Systems: A Privacy-Based Characterization. (September–October 2013). Cornell University.

What is passed from the service provider to the identity provider in a federated solution?

Answer: Tokens are commonly passed from the service provider to the identity provider in a federated solution.

What are federated identity providers?

A federated identity provider is defined with respect to a trust domain, and is responsible to assert digital identities that belong to a second trust domain. A trust relationship is established between the two.

What are the two components to a federated identity system?

Federated identity is based on a combination of several components including authentication, authorization, access control, IdPs, and service providers.

What is a federated identity solution?

Federated identity is a solution that enables users from a group of linked organizations to share the same user verification method to various applications and resources. It does this by connecting users' online identities across multiple domains and networks.