Closed austinthomsen closed 1 year ago
Hey @austinthomsen
It's certainly possible to do. From doing some testing, Google doesn't seem to easily be coerced into providing custom claims (we use the UPN claim at the moment), so we'd need to surface support for email address claims. I do have it working through changing some unexposed config settings.
The main question is, can we expect that in your customers environments that the email address provided by Google matches the UPN in active directory?
Otherwise we'd need to write some custom AD lookup logic to map the user back to the AD entity.
In my environment they definitely match. I have a feeling that is not the case for other districts though. I'm going to ask everyone in my state and see what they say! Will report back with some non-scientific data!
So far from my very small sample size (only 15 out of 600+ answered) only 1 of them has a mismatch between email and UPN. Not sure that is worth anything, but it is what I've got!
Hi Austin,
Thanks for getting back to me. Ok so OIDC support is something we can commit to in an upcoming release. Are you using v1 or v2?
We've been investigating SAML support as well, since that is something that Google does a little more naturally. Unfortunately, Microsoft don't have native authentication libraries for SAML in ASP.NET so it makes this a little tricky. We'll keep an eye on this though.
SAML would be awesome for a totally different system I'd actually prefer to connect to instead of Google. We are on v1, but we could move to v2 if needed.
v1 you can get going yourself today, provided that email = upn.
Configure the authority URL, client ID and secret in the UI, and save the config.
Exit the config app
In C:\Program Files\Lithnet\Access Manager Server\config
find the appsettings.json
file and open it in a text editor
Find the Oidc
section, edit it to include the ClaimName
and Scopes
values. JSON is very picky about commas, so ensure you get the placement right. You can use an online tool like https://jsonlint.com/ to ensure you have formatted the file correctly.
"Oidc": {
"Authority": "https://accounts.google.com",
"ClientID": "6464d71e-aa69-4aed-baf3-76fcd293b321",
"Secret": {
"Data": "dUgRzezlXV0nWybB8X24fdI5xj43Zt3NtQvFfr9aGxKrGi3ncBGk6KNqSCHsd0QY",
"Salt": "NMto/8Wzp\u002BHn6\u002B/EXzPf3g==",
"Mode": 4
},
"IdpLogout": false,
"ClaimName":"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
"Scopes": [
"openid",
"profile",
"email"
]
},
On the google side, make sure you enable the email
scope for the oauth consent screen
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs.
Is your feature request related to a problem? Please describe. I tried to set up OIDC with Google and I am getting an error message. I'm sure due to some nuance in their OIDC implementation...
Describe the solution you'd like Many school districts by me are Google districts, so official support for Google as an OIDC provider would be great.
Describe alternatives you've considered We are using smartcards, I'm just trying to increase adoption of this great tool by schools near me and I know this will come up as a request as I do more presentations.