FPS - How does enterprises control their first party sets which are internal?

[jagadeeshaby]

Example: Say an enterprise "ExampleEnterprise" has - internal.outlook.com, internal.sage.com, internal.pipeline.com and they are all internal, how do ExampleEnterprise would go and build seamless SSO on these?

As for as i understood ExampleEnterprise wouldn't register those sites on github or serve well-known/ metadata files on those domains rather they get to access enterprise level policy where they can configure the above URLs as associated sites under a first party set and everything works?

Thank you for the help in advance.

[krgovind]

@jagadeeshaby Thanks for the question. Note that, assuming that outlook.com, sage.com, and pipeline.com are valid sites; the set would actually have to include those sites. This will automatically treat all sub-domains (such as the "internal" ones) also as part of the same set.

The quick answer to your question is - yes, an enterprise-level policy can be configured to create an internal set without going through the GitHub/well-known hosting process - the relevant enterprise policy for Chrome is documented here.

However, I am inclined to ask - was your use of internal.outlook.com a contrived example, or did you mean to ask whether the Microsoft owned site outlook.com can be placed in a local FPS with their enterprise customer's (sage.com/pipeline.com) sites?

[jagadeeshaby]

Thank you,

Internal reference here meaning they aren't publicly discoverable in such case it looks like using the local FPS is an answer.

Microsoft owned site outlook.com can be placed in a local FPS with their enterprise customer's (sage.com/pipeline.com) sites?

that's an interesting way to look at, that was just an example, but we have a similar scenario where the SaaS app gets embedded into enterprise customer domains, Fo example www.enterprisecustomer.com would embed www.enterprisecustomer.saasapp.com , in such case does it make sense for enterprise customer to define local FPS with www.enterprisecustomer.com and www.enterprisecustomer.saasapp.com?

The whole part about well-known list is a huge effort in itself for both SaaS apps and enterprise customers. Another approach we are also thinking is around have a CNAME under www.enterprisecustomer.com domain which would take away the third party context alltogether.

[krgovind]

in such case does it make sense for enterprise customer to define local FPS with www.enterprisecustomer.saasapp.com and www.enterprisecustomer.saasapp.com?

I think you meant define local FPS with enterprisecustomer.com and saasapp.com, right?

We are currently working towards publishing guidance for this class of enterprise use-cases; so I will ask for your patience on this. :)

FPS may not be the best solution here, since enterprisecustomer.com and saasapp.com are not sites that the user may understand as the same "party"; but may experience saasapp.com as a vendor for enterprisecustomer.com.

We will likely recommend an alternative enterprise policy to support this use-case.

[jagadeeshaby]

I think you meant define local FPS with enterprisecustomer.com and saasapp.com, right?

My bad, corrected.

We are currently working towards publishing guidance for this class of enterprise use-cases; so I will ask for your patience on this. :)

Sure, that's good to know

FPS may not be the best solution here, since enterprisecustomer.com and saasapp.com are not sites that the user may understand as the same "party"; but may experience saasapp.com as a vendor for enterprisecustomer.com.

That make sense to me. looking forward to hear more updates on the same

[jagadeeshaby]

Any updates on this?