Allowing Gmail domain for SSO how secure it is

Allowing Gmail domain for SSO how secure it is

by Doulos Xavier -
Number of replies: 11

We have requirement where the Moodle course admin of a particular course site wants anyone with Gmail account to be able to login using Google SSO. Currently the domains are restricted. Is there a security issue with allowing any Gmail users to be able to login? What your thoughts?

Average of ratings: -
In reply to Doulos Xavier

Re: Allowing Gmail domain for SSO how secure it is

by Visvanath Ratnaweera -
Picture of Particularly helpful Moodlers Picture of Translators
Just a random video I watched last week said, there are 2,500,000,000 active Gmail users. That is quite an army to trust.
wink
In reply to Visvanath Ratnaweera

Re: Allowing Gmail domain for SSO how secure it is

by Ken Task -
Picture of Particularly helpful Moodlers

OP said a 'google domain' ... which OP's entity could have setup ... just for the entity ... not all gmail.com users.

IF google oauth2 is setup with a system admin account, a Google Login button will show in login screen.   That might confuse most users.   If they click the button and are allowed to create a account without verification or an email link is setup for them to confirm by themselves, that's going to create a new account - which means new account ID ... not that same user if they started with  manual/other auth accounts.

So what's the reason for this one course needing Google?   If Drive is activated, user goes to chooser and chooses Google Drive, there will appear a login screen in panel.   User logs in there and then they have access to their files.

https://docs.moodle.org/405/en/Google_Drive_repository

How secure is anything these days?

'SoS', Ken

In reply to Ken Task

Re: Allowing Gmail domain for SSO how secure it is

by Visvanath Ratnaweera -
Picture of Particularly helpful Moodlers Picture of Translators
I should have said 2,500,000,000 active *Google accounts*. That is close to 1/3 of the world population - there can't be more. My bad.
In reply to Ken Task

Re: Allowing Gmail domain for SSO how secure it is

by Visvanath Ratnaweera -
Picture of Particularly helpful Moodlers Picture of Translators
Saw just now that the OP indeed meant *Gmail*! See Allowing Gmail domain for SSO how secure it is. It must have been telepathy.
wink
 
Edit: Of course not. It was there in the OP, "anyone with Gmail account to be able to login using Google SSO".
In reply to Visvanath Ratnaweera

Re: Allowing Gmail domain for SSO how secure it is

by Doulos Xavier -

Thanks! Yes it does open the Pandora's box..currently only our domains and other domains are allowed. Most probably i will have to say no, citing security concers.

In reply to Doulos Xavier

Re: Allowing Gmail domain for SSO how secure it is

by Ken Task -
Picture of Particularly helpful Moodlers

"citing" ... would like to see those citations.

"other domains are allowed" - what other domains are they? 

If you can believe it:

Free Domain Reputation Checker
https://www.ipqualityscore.com/domain-reputation/

gmail.com reputation

Does mail coming from your moodle use DKIM?

'for SSO' - that's 'single signon' is that correct?

How about just acquiring an account on your system?  And as such their role would be what?  Student?   Can't do much with that!

See your domain uses validation by Microsoft Office 365.

How 'secure' is that?

Of course, it's your site!   Do what you wanna!

'SoS', Ken

In reply to Ken Task

Re: Allowing Gmail domain for SSO how secure it is

by Doulos Xavier -

Thanks Ken. Only domains that are allowed are our Google Workspace and couple of other ones which I guess are M365. Default role we are looking at is that of student.

In reply to Doulos Xavier

Re: Allowing Gmail domain for SSO how secure it is

by Ken Task -
Picture of Particularly helpful Moodlers

How about that Mr. V ... "our Google Workspace"!!!!

@OP ... "...I guess are M365."

Wow!  You don't know?

Ok then ... find out ... realize this is more than you asked for but ....

In moodlecode/admin/cli/ a getusers bash shell script.
Contains:

mysql -u root -p -e "use moodle;select id,auth,username,firstname,lastname,email,lastip,lastaccess,lastlogin from mdl_user;" > users.txt;cat users.txt;wc -l users.txt

Note: that's all on one line.

Last row in users.txt (obscured here)

13  oauth2  user@gmail.com ufn uln  uname@gmail.com epochtimestamp epochtimestamp
nnnn users.txt

See the 2nd column?  That's a google edu oauth2.   But, it's not SSO! Role of user above ... student.

And another bash shell script ... get24hr
Contains:

mysql -u root -p -e "use moodle;select userid,action,other,ip,realuserid,origin,ip,timecreated from mdl_logstore_standard_log WHERE timecreated > UNIX_TIMESTAMP(NOW() - INTERVAL 24 HOUR);" > 24hours.txt; cat 24hours.txt|more; wc -l 24hours.txt

Output looks like (row that shows me updating language pack):
11120   updated a:1:{s:8:"langcode";s:5:"es_mx";}       NULL    NULL    cli     NULL    1734777964

I can search 24hours.txt for logins:
fgrep 'loggedin' 24hours.txt
and logouts
fgrep 'loggedout' 24hours.txt

There are always more loggedin than loggedout 
Translation: users are not clicking the Moodle logout link.
Sessions for those users remain active until moodle cleans them up via task in cron job.

That really isn't a good situation!

My own habits ... I check email before logging into a moodle site that uses Google Oauth2.
If the site I go to has Google Auth2, I begin the process of logging on but don't have to provide login/password - because IAM sees me already authenticated - into IAM.

That's NOT SSO!

You don't have Incoming mail configuration setup do you?
"Inbound message processing allows you to receive and process email within Moodle. This has applications such as sending email replies to forum posts or adding files to a user's private files."

See that last part ...
".... adding files to a user's private files."
Never thought that a good idea!
Even if you had ClamAV activated.

One sure fire way to control ... anyone participating in your Moodle is required to have an address from your Google Workplace domain.  Mega user administration ... but Colleges and Unis and Corps do that!

Also ... did you notice login to these forums?  Does allow for users to select Google or Microsoft.    Hmmmmmm ...

As usual ... my 2 cents!

'SoS', Ken

In reply to Ken Task

Re: Allowing Gmail domain for SSO how secure it is

by Visvanath Ratnaweera -
Picture of Particularly helpful Moodlers Picture of Translators
Yes, the OP has come a long way from "anyone with Gmail account" to "our Google Workspace and couple of other ones which I guess are M365". Tomorrow will be another day, stars shifting in the sky.
In reply to Doulos Xavier

Re: Allowing Gmail domain for SSO how secure it is

by James Steerpike -
Picture of Particularly helpful Moodlers
That sound like a bad idea. How bad depends on who uses the course.
Moodle is educational software so many users are children or adolescents. The use of real names is widespread and forums and personal details can reveal vulnerable young people. A Moodle site should be a safe and secure supervised place. Letting anyone who can create a fake name gmail account read forum posts or directly message while posing as a student could lead to bullying or sexual blackmail. I would have to be very sure there is no possibility of that happening, or at the very least, not something that will fall on my head.
In reply to James Steerpike

Re: Allowing Gmail domain for SSO how secure it is

by Ken Task -
Picture of Particularly helpful Moodlers

@James

The OP clarified ...

"Only domains that are allowed are our Google Workspace"

Entity is an edu - higher ed., me thinks.

Even in lower K-12 Google does or did have age limit ...  when joining a Google Classroom, user is asked 'Are you a student or a teacher?'.   If they choose student, they are asked to provide birth day ... must be 13 years or older.

@James ... understand your concern ... interesting to note that even in higher ed bullying/sexual whatever/stalking can go on if students are allowed to see other students online or interact with each other.

'SoS', Ken