I'm trying to get Microsoft.Graph working within AspNetZero. I have OpenIdConnect authenticating against ADD and that is working well. A futher enhancement is some more integration with ADD for controlling access.
The requirement I have is to use a group in ADD that can allow or grant access to the application. So if a user wants to access the application the requirement is that they are part of a group in ADD. The reason for this is that our application will be in a corporate environment and the administration of users will be left to tenant administrators who are most likely system administrators within their organisation. For on-boarding new users a preferred workflow would be for a system administrator to assign a user to a group in ADD and instruct the new user that they can self register for access. In the opposite manner a user leaving the company could just be removed from the ADD group and then their access to the application will be removed.
The solution I am trying to implement is using Microsoft.Graph. I'm new to using Microsoft.Graph but I have followed through instructions from Microsoft and everything seems in order except that I am getting messages about not having permissions. I have all the API permissions setup in Azure that I should require but still cannot seem to find a simple way to connect.
I've got two questions regarding what I am trying to do.
- Is there a better way of accomplishing access being controlled through ADD groups?
- Is there any information in the solution about how to integrate with Microsoft.Graph? The ADD group stuff aside I could see being able to integrate with this service being of high value and I wonder if there is a way to create some more support within the application itself to setup.
Any advice is appreciated.
3 Answer(s)
-
0
Hi,
Instead of making this restrcition via Microsoft Graph, you can try to restrict in on Azure AD side, see https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-restrict-your-app-to-a-set-of-users#assign-users-and-groups-to-the-app. Would that work for you ?
If that doesn't work for you, could you share the error message you are getting ?
Thanks,
-
0
Hi,
I appreciate your response. I have tried the route as per your suggestion and it does work. I have however come across a couple of related problems.
When a user registers through OpenId they are activated and can now access the application. Once activated a user can just click on the OpenId button and have access. One point is that the username in the upper right is an MD5 hash of the e-mail address. I've corrected this by removing the MD5 in our code but I was curious why it was done like this? Since the user can see the MD5 value I'm not sure what the reason is but could be beneficial to know incase I am causing an issue by removing it. For end users it's not a good thing to see either.
My next issue has been tested both with and without the Md5 hash just to verify I hadn't broken anything with my change. I will details the steps below on how I am finding this issue.
- Open Id is configured and working.
- E-mail is configured in the system.
- Application access is given to user within our AD organisation.
- A user registers through the OpenId link and once activated can click the OpenId button to get access.
- Once the user is logged in they click to change their password.
- They can now click the link to say they have forgotten their password and will get an e-mail with instructions to reset.
- Once the password is reset they can now login through the username/password form rather than clicking the OpenId link.
The above steps cause an issue as when the user is removed from accessing the application through Azure AD they can by-pass by entering in their username/password since they now know their password. In this manner they are by-passing the OpenId connect which I was intending for them to use so that I can deny access through Azure AD.
Perhaps I am missing something in my configuration within AzureAD that would prevent this. Regardless I don't think that a user who is using an external authentication mechanism should be allowed to reset their password and gain access in this way.
As an aside, my original query about Microsoft.Graph isn't related to the Zero solution as I'm still facing challenges to get this working with a simple MVC application. I think it's related to OpenId and how I get the identity. In summary I can use Microsoft.Graph with application permissions but unable to use delegate permissions. This isn't an issue with your solution so I'll continue to investigate this myself.
If you could advise on the reset password for external logins and also the reason for the MD5 hash of the e-mail address that would be appreciated.
Thanks
-
0
Hi,
When a user registers through OpenId they are activated and can now access the application. Once activated a user can just click on the OpenId button and have access. One point is that the username in the upper right is an MD5 hash of the e-mail address. I've corrected this by removing the MD5 in our code but I was curious why it was done like this? Since the user can see the MD5 value I'm not sure what the reason is but could be beneficial to know incase I am causing an issue by removing it. For end users it's not a good thing to see either.
This causes problem when same user logins using multiple external login provider. But, in your case, it should be fine. By the way, you can make newly registered users passive in the settings page.
For the second issue, here is what happens. When a user logins via an external login provider (OpenIdConnect for example), a local user record is created in AbpUsers table and a random password is assigned to this user. Our system allows both local (using AbpUsers table) and external login using OpenIdConnect.
If you don't want users to login via local login, you can change the soure code of Login page. I will create a feature requet to disable "Local Login" using a setting for the next versions.
