-
Notifications
You must be signed in to change notification settings - Fork 8
Description
User story
As a user I want to access my RP, in this example a learning management system, and have access to the embedded resources without having to authorize each resource.

Case 1: User signed in to IDP before signing into LMS
- User signs into login.microsoftonline.com
- This sets a first-party cookie to the IDP
- User visits lms.contoso.com which has embedded iframe content from teams.microsoft.com, onenote.com, and embedded.third-party.com
- User can see (without extra clicks) logged-in content hosted at lms.contoso.com, teams.microsoft.com, onenote.com and embedded.third-party.com
a. The token fetches are done through the iframe embedding an iframe of login.microsoftonline.com which retrieves the token and calls postMessage() to return to the parent frame.
b. lms.contoso.com can fetch an authorization token for the user from login.microsoftonline.com
c. Each of the embedded iframes can fetch a token for the user from login.microsoftonline.com
i. teams.microsoft.com can fetch a token for the user from login.microsoftonline.com
ii. onenote.com can fetch a token for the user from login.microsoftonline.com
iii. embedded.third-party.com can fetch a token for the user from login.microsoftonline.com
d. Each of the embedded RP iframes has implicit permission for front-channel logout
Case 2: User signed out of IDP before signing into LMS
- User is signed out of login.microsoftonline.com
- User visits lms.contoso.com
- User is not signed into the LMS and clicks the sign-in button
- User is redirected to … <fuzzy here, is this nav based cookie setting?>
- User is redirected back to the lms.contoso.com
- Goto: Case 1 step 3.
Out of scope:
- User goes to login.microsoftonline.com and clicks logout
- User receives authorization grants for embedded resources
Q: Do the embedded iframes need access to the login.microsoftonline.com cookie outside of fetching tokens?
Q: What types of tokens do the iframes need access to? id_token, access_token, refresh_token, other?
Context of the story
Assumptions: The IDP and the LMS are not the same first-party
This specific case of a learning management system would be EDU, but a similar setup exists in consumer and enterprise contexts as well.
Q: For the consumer context, what is the behavior the consumer would expect/want here? Does the consumer expect the embedded RPs and login.microsoftonline.com to know about each other?
Should this be considered sanctioned or unsanctioned tracking?
Unknown / TBD
Explicit list of parties involved
- User
- UA
- IDP
- LMS RP
- One or more 1st / 3rd party embedded RPs
Privacy implications
- There is sharing of user information between the embedded RPs and the IDP for which the user has not granted explicit consent.
- Each embedded RP now knows the user has an account at IDP
- The IDP knows the user has accessed each of the embedded RPs in some fashion
- The user consent may have been granted explicitly by the administrator of the users domain when configuring the LMS.
- This consent can include the grants the RP is permitted to access
- This may leave certain types of information the user is allowed to self-consent too (e.g. may RP access for calendar). If the authorization is not in the list of self-grantable permissions it is blanket denied.
- If consent is requested, what does it mean if the user is not authorized to grant the consent? (If all consent has to be granted by the administrator, the user has no choice but to answer no)
- If the user consents to “lms.contoso.com wants to sign in with your login.microsoftonline.com” account, is that consent transitive to embedded resources?
- In the current 3rd party cookies world the answer is yes
- In a non 3rd party cookie world with CHIPS/FPS, if the user visited lms.contoso.com and signed into login.microsoftonline.com with an embedded iframe, the answer would be yes if the cookie is set Partitioned as the cookie would be keyed with [FPS(lms.contoso.com) login.microsoftonline.com] and each embedded iframe would use the FPS of the top-level origin when accessing the partition.
Complicating characteristics
[TBD]
Additional information
[N/A]