Enterprise SSO

[samuelgoto]

Enterprises rely on identity federation to enable single-sign-on on the Web today. Here is a typical example:

1. Sign-in to https://corporation.com with your corporate credentials
2. Buy stuff with your corporate credit card
3. Go to report expenses on https://www.expenses-sass.com/
4. Sign-in with your corp accounts on expenses-sass
5. Report expenses tied to your corporate account

The problem?

Unfortunately, step (4) depends on many low level primitives that are being tightened up as a result of cross-site tracking, namely third party cookies, link decoration and postMessage.

Can First Party Sets help?

FPS is a formulation to allow user identity to span related origins, where consistent with privacy requirements. However, the intent of FPS is to bundle origins within a unifying organization. For example, https://google.com, https://google.co.uk, and https://youtube.com are owned by the same entity, as are https://apple.com and https://icloud.com, or https://amazon.com and https://amazon.de.

Back to our original example, it is clear that https://corporation.com and https://www.expenses-sass.com/ are not owned by the same organization, but rather a contracted service provided by two different organizations, so doesn't fit the FPS model.

Enterprise Policies?

The idea behind enterprise policies is that enterprises issue machines for their employees to do their work, and in doing so, have a tighter level of control and expectations about their use.

Enterprise policies are policies set by enterprise admins for machines that the corporation issues for their employees. These policies change a variety of browser behavior.

Enterprise SSO is different from consumer SSO in two ways:

• In enterprise SSO, it is critical to share global identifiers. For example, expense reporting and vacation reporting is a typical contracted service that a corportation delegates, but clearly needs to join your identity with your corporation.com identity.
• In enterprise issued machines, there is an expectation that employees will be using them for work and that their employer is aware of what they do on corporate resources.

The idea then, is to add enterprise policies that enable enterprise admins to set policies that lower the browser interventions for a specific set of origins.

One proposal is to allow enterprise admins to say “this specific origin IDP.example can communicate with other origins”. With that permission, IDP.example is then responsible for making a determination of which domains it trusts to integrate with.

For example, corporation.com could have an enterprise policy setting accounts.corporation.com as the IDP, which would allow things like https://www.expenses-sass.com and https://www.vacations-sass.com to pass through but disallow other unintended origins.

One shortcoming of enterprise policies is that they will probably need to be set specifically for each browser the employees of a corporation are allowed to use, so there is an extra cost involved to admins to manage their fleet of devices.

WebID and Enterprise Profiles?

WebID is a formulation to preserve federation under tighter privacy controls. However:

• Observation Update README.md #1: Enterprise SSO has arguably a different set of privacy expectations compared to consumer’s identity federation. Specifically, enterprises issue machines that have a different set of expectations of use.
• Observation Small grammar fix. #2: WebID’s design largely depends on a deployment structure that isn’t exactly applicable to enterprises: there are thousands of IDPs rather than a handful and each IDP typically connects with a handful of RPs rather than thousands. So, from a deployment perspective, enterprise policies have a much faster turn around compared to redeploying all of the enterprise IDPs/RPs.

In BYOD (bring your own device) use cases, employees use their own personal devices to access corp resources. One interesting idea to be explored is using WebID to make the set up enterprise policies, possibly even kicking off a partitioned enterprise profile.

[samuelgoto]

Somewhat related problem that often gets discussed in conjunction with this problem: First Party SSO.

[samuelgoto]

I'm going to close down this issue now that we have a fully dedicated section in the explainer:

https://github.com/samuelgoto/WebID#enterprise

Feel free to re-open if you fee like I failed to capture something from here in that section.

[bc-pi]

Did you mean to link to your personal github?

[bc-pi]

I don't think deferring to Enterprise Policies and FPS is really sufficient.

[samuelgoto]

Re-opening this to make sure this doesn't fall through the cracks.

[samuelgoto]

We broke this into many smaller parts since this was initially filled, so I'm going to close this as we make progress on the individual parts. Feel free to re-open if you feel like there is something actionable here.