Entra SSO for 3rd party web applications

[psynegy]

We get a number of requests from students and staff trying to use their Entra credentials to log into various websites. We've largely ignored them unless they're websites that the school has a relationship with, but it feels that we are possibly being unnecessarily restrictive.

 

Take typing.com for example, it's a free website that helps students learn to type, sounds great! From our perspective, having students sign in with their Entra account is also great, it means we're automatically securing their account on that website with our policies and it means they don't come and ask us what their password they set 2 years ago for typing.com is. We also require them to click sign in with MS on all our school purchased systems, so you can see why they would be drawn to it.

 

With everything we have to do regarding DPIA for companies that we send data to, would we need to complete some sort of assessment for sites like this? The permissions they request are fairly vague, and I can't reason from the terminology if I'm approving the application to read the data of all users, or just the ones that have ever used the website to sign in. It says "read the profile of signed-in users" and "maintain access to data you have given it", but also says "this app will get access to the specified resources for all users in your organisation...

 

 

Assuming it does only provide the information for users that use the system, I would have thought that the data we would be providing would be no more than they would be required to enter themselves to sign up with a password?

 

What do you do in this scenario? Do you have a policy to cover this sort of request?

[GrumbleDook]

I think you have hit on the most relevant term… 3rd Party!

You have two types of site you are being asked to link to. The one you want is where you have a relationship with them, are clearly the data controller and they are the data processor, and you have completed any checks and risk assessment (including data requested with permissions during setup of SSO).

The one you don’t want are the consumer / extra bits that you don’t control but are requested by all sorts of sites. These are their own data controller and could range from really good educational tools to dating websites!

These would have a direct relationship with the end user and would count as Information Society Services, would come under the Children’s Code and likely require Consent.

So yeah … you are right to avoid this, no matter what you are using … Google, MS, Apple …

[mavhc]

Why is that different to them signing in with any other account though?

 

All they're doing is saving the email address you gave them

[enjay]

Why is that different to them signing in with any other account though?

 

All they're doing is saving the email address you gave them

 

It isn't really, but since we should be doing DPIAs on every website which a teacher tells a student to sign up with, the main question is still valid.

[GrumbleDook]

Why is that different to them signing in with any other account though?

 

All they're doing is saving the email address you gave them

 

If they use their school email address and decide on their own username/password then the school really has no involvement. The relationship is between the site (Data Controller) and the student/teacher (Data Subject)

 

If SSO is involved, then the site is using personal data that the school owns and controls. There *is* a direct relationship and you are making a decision about what data can be transferred to another Data Controller. And this is probably being done with a data sharing agreement.

 

Basically? The illegal transfer of data to an unverified Data Controller.

 

Can it be made legal? Yes, of a fashion. We are now talking about consent to share data with 3rd parties (I.e. separate Data Controllers and *not* Data Processors) and managing everything that goes along with it.

 

It is untested in court or ICO investigations as to whether the school has to do Due Diligence to ensure any Data Controller they share data with is up to spec with respect to The Children’s Code, but I am sure interested parties would insist on it.

 

As a vendor, we are clear we are a Data Processor. We have to be and that means having the relevant agreement in place.

 

As a consultant within the EdTech provider community, I am always clear about the limitations and implications of becoming a Data Controller. Only those who sell on a direct to family basis tend to opt for this, and try to keep their school version separate.

[mavhc]

What data is being transferred?

[Tefters]

I allow this for 3rd party websites but only through approval on me (admin). Check the websites T&C's about data handling and decide from there.

 

People have mentioned a few bits above on XYZ reg's etc... but if you don't facilitate some of it then teachers will either tell students to sign up manually or throw csv spreadsheets over email with information, then ofcourse there is the end user experience of 1 logon to rule them all.

 

Personally, it's better than having the teachers do their own thing and you can always pull the connection at anytime if needed.

Edited September 26, 2024 by Tefters

[enjay]

If they use their school email address and decide on their own username/password then the school really has no involvement. The relationship is between the site (Data Controller) and the student/teacher (Data Subject)

 

If SSO is involved, then the site is using personal data that the school owns and controls. There *is* a direct relationship and you are making a decision about what data can be transferred to another Data Controller. And this is probably being done with a data sharing agreement.

 

I guess I'm not making a distinction in my head between the two routes. Either way, the school is in effect sharing the data, whether directly (by SSO) or indirectly (by telling the child they must share it). I accept the legality of it may be different though.

[mavhc]

I'm not sending any data to the 3rd party, I'm reducing the amount of data the 3rd party stores by the most important item, the same password they use on every site.

 

They'd still use their email address, just now they're not sending a password

[HPlum78]

@ first glance on Typing.com I cannot see what the app is actually asking for in terms of scopes and permissions, but my gut feeling is that its going to be User.Read.All. Here is the JSON for that:

 

{

"aboutMe": "String",

"accountEnabled": true,

"ageGroup": "String",

"assignedLicenses": [{"@odata.type": "microsoft.graph.assignedLicense"}],

"assignedPlans": [{"@odata.type": "microsoft.graph.assignedPlan"}],

"birthday": "String (timestamp)",

"businessPhones": ["String"],

"city": "String",

"companyName": "String",

"consentProvidedForMinor": "String",

"country": "String",

"createdDateTime": "String (timestamp)",

"creationType": "String",

"customSecurityAttributes": {

"@odata.type": "microsoft.graph.customSecurityAttributeValue"

},

"department": "String",

"displayName": "String",

"employeeHireDate": "2020-01-01T00:00:00Z",

"employeeId": "String",

"employeeOrgData": {"@odata.type": "microsoft.graph.employeeOrgData"},

"employeeType": "String",

"faxNumber" : "String",

"givenName": "String",

"hireDate": "String (timestamp)",

"id": "String (identifier)",

"identities": [{"@odata.type": "microsoft.graph.objectIdentity"}],

"imAddresses": ["String"],

"interests": ["String"],

"isResourceAccount": false,

"jobTitle": "String",

"legalAgeGroupClassification": "String",

"licenseAssignmentStates": [{"@odata.type": "microsoft.graph.licenseAssignmentState"}],

"lastPasswordChangeDateTime": "String (timestamp)",

"mail": "String",

"mailboxSettings": {"@odata.type": "microsoft.graph.mailboxSettings"},

"mailNickname": "String",

"mobilePhone": "String",

"mySite": "String",

"officeLocation": "String",

"onPremisesDistinguishedName": "String",

"onPremisesDomainName": "String",

"onPremisesExtensionAttributes": {"@odata.type": "microsoft.graph.onPremisesExtensionAttributes"},

"onPremisesImmutableId": "String",

"onPremisesLastSyncDateTime": "String (timestamp)",

"onPremisesProvisioningErrors": [{"@odata.type": "microsoft.graph.onPremisesProvisioningError"}],

"onPremisesSamAccountName": "String",

"onPremisesSecurityIdentifier": "String",

"onPremisesSyncEnabled": true,

"onPremisesUserPrincipalName": "String",

"otherMails": ["String"],

"passwordPolicies": "String",

"passwordProfile": {"@odata.type": "microsoft.graph.passwordProfile"},

"pastProjects": ["String"],

"postalCode": "String",

"preferredDataLocation": "String",

"preferredLanguage": "String",

"preferredName": "String",

"provisionedPlans": [{"@odata.type": "microsoft.graph.provisionedPlan"}],

"proxyAddresses": ["String"],

"responsibilities": ["String"],

"schools": ["String"],

"securityIdentifier": "String",

"serviceProvisioningErrors": [

{ "@odata.type": "microsoft.graph.serviceProvisioningXmlError" }

],

"showInAddressList": true,

"signInActivity": {"@odata.type": "microsoft.graph.signInActivity"},

"signInSessionsValidFromDateTime": "String (timestamp)",

"skills": ["String"],

"state": "String",

"streetAddress": "String",

"surname": "String",

"usageLocation": "String",

"userPrincipalName": "String",

"userType": "String",

 

"calendar": { "@odata.type": "microsoft.graph.calendar" },

"calendarGroups": [{ "@odata.type": "microsoft.graph.calendarGroup" }],

"calendarView": [{ "@odata.type": "microsoft.graph.event" }],

"calendars": [ {"@odata.type": "microsoft.graph.calendar"} ],

"contacts": [ { "@odata.type": "microsoft.graph.contact" } ],

"contactFolders": [ { "@odata.type": "microsoft.graph.contactFolder" } ],

"createdObjects": [ { "@odata.type": "microsoft.graph.directoryObject" } ],

"directReports": [ { "@odata.type": "microsoft.graph.directoryObject" } ],

"drive": { "@odata.type": "microsoft.graph.drive" },

"drives": [ { "@odata.type": "microsoft.graph.drive" } ],

"events": [ { "@odata.type": "microsoft.graph.event" } ],

"inferenceClassification": { "@odata.type": "microsoft.graph.inferenceClassification" },

"mailFolders": [ { "@odata.type": "microsoft.graph.mailFolder" } ],

"manager": { "@odata.type": "microsoft.graph.directoryObject" },

"memberOf": [ { "@odata.type": "microsoft.graph.directoryObject" } ],

"messages": [ { "@odata.type": "microsoft.graph.message" } ],

"outlook": { "@odata.type": "microsoft.graph.outlookUser" },

"ownedDevices": [ { "@odata.type": "microsoft.graph.directoryObject" } ],

"ownedObjects": [ { "@odata.type": "microsoft.graph.directoryObject" } ],

"photo": { "@odata.type": "microsoft.graph.profilePhoto" },

"photos": [ { "@odata.type": "microsoft.graph.profilePhoto" } ],

"registeredDevices": [ { "@odata.type": "microsoft.graph.directoryObject" } ]

}

 

So you tell me is that what you would normally allow access to?

[HPlum78]

Ah well color me surprised Typing.com have got back to me and they are one of the better companies out there and have scoped their app right down to only what they need, and have confirmed that they are not scraping all of the attributes for the user out of the tenant.

 

That dont mean you should not be mindful of just what you are accepting when clicking on that consent button for application permissions, and any that are asking for application rather than delegated permission should be a NO until you are absolutely happy with that requirement.

Edited September 26, 2024 by HPlum78

[GrumbleDook]

Yep, some of them out there really do grab a lot more data than is needed.

The other really important fact is that unless you have a formal relationship with them (Data Processing Agreement or Data Sharing Agreement) it is likely to be an illegal transfer.

If your staff will get the student signed up anyway then that is a serious issue on data protection, privacy and safeguarding grounds. This should involve your DPO and your senior leadership team.

In the interest of protecting yourself, if you are told to allow it, document it. Cover your behind. The school would not accept getting science supplies without thinking about COSHH, or ask random builder to sort out a new block for them.

I’ll dig out a few old posts that give examples of the problems involved and how close to home it can get.

[mavhc]

Ah well color me surprised Typing.com have got back to me and they are one of the better companies out there and have scoped their app right down to only what they need, and have confirmed that they are not scraping all of the attributes for the user out of the tenant.

 

That dont mean you should not be mindful of just what you are accepting when clicking on that consent button for application permissions, and any that are asking for application rather than delegated permission should be a NO until you are absolutely happy with that requirement.

 

It's telling that you're the first person to ever ask them about it, can you paste the new json when it's available?

[Roberto]

Can it be made legal? Yes, of a fashion. We are now talking about consent to share data with 3rd parties (I.e. separate Data Controllers and *not* Data Processors) and managing everything that goes along with it.

 

It is untested in court or ICO investigations as to whether the school has to do Due Diligence to ensure any Data Controller they share data with is up to spec with respect to The Children’s Code, but I am sure interested parties would insist on it.

 

Not in edu any more, not doing anything with childrens' data any more, but in my current role we would absolutely do due dilligence on this for our user population. I've actually turned a few vendors down because the user data were asking for wasn't justified by the stated aim of the service.

[HPlum78]

Not in edu any more, not doing anything with childrens' data any more, but in my current role we would absolutely do due dilligence on this for our user population. I've actually turned a few vendors down because the user data were asking for wasn't justified by the stated aim of the service.

 

You are bang on with this, the times I look at these requests (from big IT suppliers as well) and think to myself really all of those! in my mind it comes down to being lazy and taking the boiler plate auth flow code and doing absolutely zero to it and just bolting it into the code to make the application work... I bet 90% of the ones I see dont need or do anything with the attributes/ permissions that they are requesting but they simply dont scope the request down to accomplish what it is they are trying to achieve. Not so good from a data security/ security perspective mind.

 

Check these requests and turn off the end users ability in your tenants that allows them to accept these as well.

[enjay]

I bet 90% of the ones I see dont need or do anything with the attributes/ permissions that they are requesting but they simply dont scope the request down to accomplish what it is they are trying to achieve.

 

We saw that here with some online quiz or assessment platform, I forget exactly what it was. When the Wonde came through, it included name, year group, etc but also PP, SEN and Ethnicity. I queried this and was told "some of our customers buy a module which analyses student marks by these categories, so we request it as standard". They did subsequently send a new request just for what we need, but I wonder how many other people just agree without thinking or realising - it certainly goes to show why the only staff with Wonde/Groupcall/etc. admin access, or indeed any IT staff who might install "a little connector app" on the SIMS server, also have solid GDPR training.