Hi,
I am trying to get SSO implemented with Azure AD connecting to Open ID Connect in ChirpStack, but it doesn’t seem to be working. I hit a loop where we get the error below.
Just for the sake of asking, do users already have to be in the user table before SSO will work?
I also have the ‘registration’ config variable set to true, so this shouldn’t be an issue unless the functionality is bugged.
Can anyone provide a sanitized example of how these fields would be populated, particularly the Email field? I am using the docker images at log level info, but it isn’t giving significantly helpful logs, debug didn’t give anything helpful either unfortunately. Getting a sample for this would be very helpful for my investigation, thanks.
Thanks in advance for any help anyone can give.
Would really appreciate if anyone could provide a hand on this?
I have no experience with Azure AD, but is the returned email_verified field set to true in the OIDC claims? I believe that is what the error is about.
1 Like
Hi Orne,
We were thinking that may be part of the issue, but were having trouble modifying the code to debug. Is there any way to turn off the dependency on email_verified or is that fully integrated into the code, as I see the implementation of Azure AD I have to communicate with doesn’t have email_verified as a usual field.
There is no worry if this is not easily doable, I am just trying to get as many options as possible.
Thanks for the response regardless!
@brocaar Hi Orne,
While it might not be feasible, would there be some possibility of making the email_verified field optional? I have seen in OIDC docs that it is an optional claim.
It would be great if this could be supplied as env variable through conf. Default value we can supply ourselves, otherwise if exists in OIDC token, pull that value.
This might obviously not be an improvement, so just a suggestion.
Thanks
Isn’t there a way to make sure that Azure AD returns email_verified true? The reason why this is validated is that if an user already exists within ChirpStack the email will be used to associated the OIDC provided id with the user within ChirpStack.
Therefore you really want to make sure that the OIDC provided email is validated, as else there could be an option that somebody could hijack other accounts.
Do you have any (references to) documentation about the Azure AD returned claims?
Hi @brocaar,
I have contacted people to make changes, but I have hit another problem. I have asked the people that handle the Azure side of things to add email_verified as a field, so that part is fine, but I am now hitting an issue that might be related to GO itself, and you might be able to lend a hand to.
Our SSO is mostly working, but for the fact that the code cannot seem to handle email_verified, however the value arrives as a string, and we are now getting the error that it is not handling the unmarshal correctly as it only expects a bool.
I have seen an answer on StackOverflow surrounding a similar issue and this was the proposed fix. I suppose it tells the marshaller to potentially expect to parse a string?
What is your opinion on this?
@brocaar
Giving another update on this. We have tried to configure the Azure token to pass email_verified, and the field is passing, but no matter what config we give, it continues to fail.
The example of our claim is below, but as you can see in the Value field, it must be “True” to work with Azure format, but Go expects true with lowercase t.
This might mean that it might never be able to interpret the value as a bool correctly.
I managed to get this working by adding assume_email_verified=true in the application server configuration. Thanks to the chirpstack team to get this new flag added in latest version of application server.
Now the user can be authenticated with Azure AD, and if the user is not present in the Chirpstack application, they will get the following screen after authentication is successful: As a global administrator, I can also see that user as present in the All Users section of the application.
One question on this:
Is there a way to show the user an authorized failed message instead of a blank page after authentication?
1 Like
