Custom Oauth2 Configuration

Re: Custom Oauth2 Configuration

by Ken Task -
Number of replies: 3
Picture of Particularly helpful Moodlers

Just to follow up ... resolved.   Not by me, but some other folks that are quite sharp. ;)

" .... Remind me to tell Moodle dev’s they need some documentation and useful tooltips.  We shouldn’t have to reverse engineer their code to figure out what to do, and there’s zero chance we would have guessed to use name “discovery_endpoint” verbatim…"

Have to assume that was on the openid server end.

Did find an online tool for OpenID Connect Provider:

https://op.certification.openid.net:60000/

And the openid server providing was behind cloudflare ... that gave us curl errors for a while - CentOS 6.  Wonder if Ubuntu 16.04 or CentOS 7 would be better?

Handy testing for that via command line:

curl -vvv https://urlforwellknownservices

Can't wait for someone who runs Windows to try it! ;)

'spirit of sharing', Ken


In reply to Ken Task

Re: Custom Oauth2 Configuration

by Ken Task -
Picture of Particularly helpful Moodlers

Well, this is probably waisted data bits/time (cynical, huh?) .... but I'll ask ...

Custom Oauth2 there is Discovery in it's config.   Tool tip on that says if the end points can talk, the IDM system will populate user fields - which it did for two test users.   If not, then Moodle admin needs to manually map user fields fields and endpoints information.  

The manually mapping of fields provides a pick list shown below - the internal being Moodle fields.

internal field names














Know one can use language customization to change their labels ... what shows ... is there a way to change what shows above to reflect the same changes in language?

Looks like this will lead to customizing some core code. :\   Trying to avoid that if at all possible.

Thanks, in advance, Ken


In reply to Ken Task

Re: Custom Oauth2 Configuration

by Ken Task -
Picture of Particularly helpful Moodlers

Adding to this BIAF ('blog in a forum') ....

Seems the agenda and items to discuss/cuss as well as who has tested what and reporting on those test, is kinda out the window every WebEx meeting ... anyhoo ... the only way I can see anything with this CustomOauth2 setup is from the Moodle end.

One of the features that is interesting is linkedlogin:

https://docs.moodle.org/33/en/Linked_logins

I can confirm that appears to work ... only way I can confirm is to look at web server logs and DB tables.   And that's what this is about .... what's in those tables ....

select * from `mdl_auth_oauth2_linked_login

does show accounts that have been linked.

But in looking at mdl_user table for the same users, their auth has not changed ... still manual.

They do have to confirm ... apparently they have 30 minutes to do so.   Dunno how that confirmation is done ... I imagine EMail (which has been turned off on this sandbox server).  Four users so far are in that table.   One user in the table hasn't confirmed.

For that info to show up in tables, those 4 had to click the button for logging into the IDM server ... which, BTW, appears to be behind CloudFlare *and* on Amazon (guess they have big plans for it). 2 of those users show in mdl_user as oauth2 ... 2 of those users in mdl_user show manual still.

Since the mdl_user table hasn't changed and still shows auth is 'manual' ... not oauth2 ... am wondering now IF that means users could still use the 'standard' login as before ... the manual dialog boxes username/password.   Those users could login either way.

Since customoauth2 new in 3.3 and 3.4 am wondering if behavior such as described above will change one day in an update or upgrade (kinda like how Google Docs did in Repos in version 2 of Moodle). 

Now I know that's a crystal ball question ... but ....

Anyhoo ... not that the suspense will peak anyone's interest ... but I'll report back to this BIAF when/if any new discovery is made.  Just hope, for the entities sake, they haven't gone down a road with customoauth2 that one day causes major disruption.

'spirit of sharing', Ken

In reply to Ken Task

Re: Custom Oauth2 Configuration

by Ken Task -
Picture of Particularly helpful Moodlers

Tested with Google on another server because I could access both ends. 

A user that had a manual account using email address as login can link their oauth2 credentials in the Moodle.   Must confirm via Email. 

In mdl_user table, the auth column, is *not* changed ... leaves it for manual.    And, the user can use either the normal login dialog boxes OR the Oath2 button for Google.   That's great in that the user account keeps the same ID so no work done prior to linking is lost.

However, if use is still allowed to edit profile some 'dis-connect' could be created by user.

But, kinda begs a question for customOauth2 setup ... unless there is something special that moodle acquires from the issuer server/system, why do it?   My guess is the population of other profile fields in Moodle that are not normally used would be mapped (actually have to be mapped).

But, unless something is done via webservices from the identity management server to populate the additional fields that are set to required, Moodle Admin level user is still using CSV to update those accounts and required fields.   Uhhhh ... what's the point?

Am assuming that if discovery is off or not functioning, anything new on the ident management system won't be picked up by the Moodle.

So much for automation.

Closing this blog in a forum.

'spirit of sharing', Ken