I would like to be automatically logged on a website using my password an login that are used on my computer when i open an AD session.
Connection must be granted if i'm in the right AD group .
Any advices ?
The easiest solution would be to use the built-in ASP.NET Membership and Role system and just use the "Active Directory" membership and role providers.
That way, your user is automatically authenticated, and you can use role-based security in ASP.NET to do something like:
[PrincipalPermission(SecurityAction=Demand, Role='MyAppRole')]
Put this on your critical or sensitvie methods to allow or refuse access to your app.
With the same method, you can also add protected subfolders to your application and protect them by specifying who has access (or not) in your web.config (in that folder).
See a few links for additional details:
http://blogs.msdn.com/gduthie/archive/2005/08/17/452905.aspx
http://slalomdev.blogspot.com/2008/08/active-directory-role-provider.html
http://msdn.microsoft.com/en-us/library/system.web.security.activedirectorymembershipprovider.aspx
Hope this helps a bit.
Marc
Related
I have set up a B2C instance OK and managed to get a basic Blazor (server) app working with it a using the Microsoft Identity Platform (using AD groups for permissions - it was a hassle but works).
However, I'm trying to use an external Azure AD as a custom identity provider in the user flow, so that I am not just restricted to just email/id/social accounts, but can have guest accounts from other directories use the app without having to manage their sign-in's. To do that I performed a web app registration in the AD tenant that I wanted to use to authenticate those accounts against (as suggested in a couple of tutorials).
The application I registered in the external AD has a Redirect URI in the format "https://{My B2C Directory Name}.b2clogin.com/{My B2C Directory Name}.onmicrosoft.com/oauth2/authresp", which matches the name of my B2C instance, and I have added the client id and secret generated from that app registration and put the details into the custom identity provider I have created for the sign-in flow, as per the instructions here (including the mappings etc.):
https://learn.microsoft.com/en-us/azure/active-directory-b2c/identity-provider-azure-ad-single-tenant?pivots=b2c-user-flow
I also found a slightly older tutorial here, which is pretty similar (different mappings) that I've tried to follow (and adapt the bits that are out-of-date).
https://medium.com/the-new-control-plane/connecting-azure-ad-b2c-to-azure-ad-via-the-b2c-custom-identity-provider-42fbc2832e32
However when I run the user flow I get "AADSTS900971: No reply address provided." - this happens even when I run the flow directly from the User Flows tab in B2C with a 'Reply URL' explicitly set to "http://jwt.ms" (just to capture the token contents).
I'm confused about the reply URL being missing because they exist in both registered apps. Also, it's not saying they're mismatched, just that one isn't set at all (but appears to be).
It feels like I'm missing something simple - does anyone have any idea what that might be?
Ok so I did a couple of things to resolve this:
Re-registered the application in the AD I want to authenticate with (following this tutorial again: https://learn.microsoft.com/en-us/azure/active-directory-b2c/identity-provider-azure-ad-single-tenant?pivots=b2c-user-flow)
I was careful to ensure that the redirect URI in the format:
https://{B2C Instance Name}.b2clogin.com/{B2C Instance Name}.onmicrosoft.com/oauth2/authresp
was all lower case.
I also had to change from just a 'sign-in' user flow to the 'sign-up, sign-in' one, and then applied the custom identity provider to that flow. Apparently you need that even for users from another AD to be able to complete their invite process (otherwise you just end up with a user doesn't exist error - even if you've invited/added them to the B2C users list).
I also elected to 'Grant admin consent for Default directory' under the API Permissions tab for the application being registered in the external AD (to be used for the custom identity provider).
The flow seems to work now. The only thing that would be useful would be to have an invite only sign-up, sign-in flow so that you could invite specific people without breaking the invite process.
If anyone knows how to do that please do post something.
How can I find out what admin permissions are blocking the user from signing in to an Azure AD app?
I am setting up an App Registration in the Azure AD portal to be used with my Service Fabric cluster. The app registration does basic auth and only has one Required Permission configured: Sign in and read user profile (which does NOT require admin permission).
My tenant has the "Users can consent to apps accessing company data on their behalf" setting to "Yes", so it's not that.
Also, the /authorize request doesn't have any resource parameter, so it's implicitly asking for the permission I configured: Azure AD's Sign in and read user profile.
However when an non-admin user attempts to sign it, I still get the error:
AADSTS90094: The grant requires admin permission
I reproduced the scenario and this is what I observed. Found a workaround, hope it helps.
First I created a Service Fabric (SF) cluster secured with AAD authentication using the steps described here, using an AAD tenant where I am not a global admin.
Then I tried to login to Service Fabric Explorer (SFX) and I got this error:
AADSTS50105: The signed in user is not assigned to a role for the
application 'f8c79129-deb7-4a21-a6e0-ec29e88298ef'
This is expected, because the user must be assigned to a role (Admin or ReadOnly) in the SF application that represents the cluster. So I went to AAD > Enterprise Applications > found my cluster app and under Users and Groups I added myself to the Admin role. Notice that the fact that a regular user can administer the roles of an application that the user owns is something new, it's available since a month or so -- before that, a regular user couldn't administer the roles of an application.
Then I tried to login again to SFX and I got a different error:
AADSTS65005: Invalid resource. The client has requested access to a
resource which is not listed in the requested permissions in the
client's application registration. Client app ID:
f8c79129-deb7-4a21-a6e0-ec29e88298ef. Resource value from request: .
Resource app ID: 00000002-0000-0000-c000-000000000000. List of valid
resources from app registration: .
00000002-0000-0000-c000-000000000000 is Windows Azure Active Directory. For some reason SetupApplications.ps1 doesn't assign the Sign in and Read User Profile permission to the SF cluster application. So I edited the application and I assigned that permission, just like you showed in your print screen. Notice that SetupApplications.ps1 has a parameter AddResourceAccess (not mentioned in the doc) that adds that permission, not sure why it doesn't add it by default. Perhaps it isn't needed when you run SetupApplications.ps1 as a global admin, and the scripts/doc assumes that you are a global admin.
Then I tried to login to SFX again and I got the same error that you observed:
AADSTS90094: The grant requires admin permission.
So I checked the SF application under AAD > Enterprise Applications > found the SF cluster app > Properties. User assignment required is configured "Yes". I changed it to "No" and tried to login to SFX. This time it worked OK, I could consent and access the SFX console. Then I changed User assignment required again to "Yes".
One can argue if the SF app really needs User assignment required > Yes because anyway if a user is not assigned to the Admin or ReadOnly role, SFX will try to fallback to client certificate authentication.
In either way, the AAD behavior is confusing. At least, the error should be more descriptive and point to the User assignment configuration. Perhaps the current behavior has to do with what I mentioned before, that regular users can now administer roles. Perhaps the behavior is being improved.
I've written a security module for my MVC intranet that allows administrators to grant permissions to users for certain functions like viewing, editing, deleting etc. When an intranet user visits a page, the underlying security module checks the SQL database to see if an administrator has given them access to perform the task and, if they have the required permission, they can click a link or whatever.
What baffles me is that the above system doesn't work unless I republish the website after the administrator has granted the permission. The permission is stored correctly in a permissions table in the database but when the user tries to use the permission it doesn't work. As far as I can tell my security module is completely standalone and is just a case of reading and writing to a database using static methods like this:
if (SecurityManager.HasRole(Request.ServerVariables["AUTH_USER"], "edit")) { }
I'm sure this is just a basic flaw in my understanding but does anyone have any ideas how I can get this to work?
We have the angularjs application where we have different roles associated to the users. For ex: the two roles are Admin and Local. Based on the role, we show some menu items for the Admin and adds more features/screen to the Admin .
The userInfo with the Admin Property is returned from the login response and based on what we decide which all menu and screens to be rendered .
But if we user the developer tool, and the set the break point where the admin property is used, and set the admin property as true the user even he is a local user would be able to access admin privileges .
In short who has some idea about the javascript code can get the admin privileges . Is there any idea other than minification of the code to prevent this kind of security threats
Thanks
As the front-end of your application will run on the client machine there is actually no way to stop a user from debugging or modifying the code. Thus it's impossible to prevent someone from tricking their local instance of the application to think it's signed in as an administrator.
If you simply want to hide the admin interface, one possibility is to have separate (or additional) templates for administrators and restrict access to these based on the user's privilege. If there is anything to be gained from this is up to you. You will still need to validate the rights to execute any privileged action on the server anyway. Obtaining administrative privileges on the client must never be the same as obtaining them on the server side.
I can check user in active directory, if he exist then I give him permission to open app window, but what if an application has many levels of permission? Do I create special groups of permission in active direcotry and check if user belongs to one of them? . Can application log in automaticaly, or there is always need to enter password?
Active Directory can fulfill two related but seperate functions for an application: Authorization and Authentication.
Authentication is validating that the person using your application is a valid user. If you have the user's credentials (i.e. the application prompts the user for their username and password), you can authenticate them against AD by attempting a connection using their username/password.
Authorization is what lets you determine the level of permissions a particular user has in your application. Active Directory groups are a relatively straightforward and flexible way to implement the various permissions levels. Typically, I will create very fine-grained permissions groups that represent each securable action users can perform in the application (i.e. CanDeleteWidgets, CanAddWidgets, CanEditWidgets ). Then create functional or role groups where you place the users for that role (i.e. Managers, Coordinators, Technicians, etc). Finally, you just nest the role groups into the permissions groups so if, for example, the business requirement is that Managers can delete widgets, you would add the Managers group as a member of the CanDeleteWidgets group. While this may seem more complex, it makes it extremely simple to respond to changing business security requirements (i.e. "Technicians need to be able to delete widgets" - Piece of cake. Add the Technicians role group to the CanDeleteWidgets permissions group and you're done).
As far as logging in automatically, yes, there are a number of ways you can automatically log in a user. For winforms apps, you should just be able to grab the currently logged in user and use that. For web apps, if you can use integrated authentication, you end up with the same thing. Your web server will handle the authentication piece and send over the DOMAIN\USERNAME of the user in a server header variable.