I have simple ASP.NET MVC survey generator, that based on the URL displays various forms and persists data input from user:
http://survey.mydomain.com/ConferenceFeedback
http://survey.mydomain.com/DailyReport
etc.
Some of these subapps should be accessible by everyone, some by specific set of users. My user store is Azure AD. Is there is any Azure AD related feature that is a good match for my authorization scenario, where I could assign user rights on Azure side and just validate some claims or roles in my app per user request?
You might want to look into application roles. You can define roles representing the various subapps you want to model, and you can assign users to them accordingly. On the application side, you can examine the incoming claims set and decide whether the user has the necessary role claims for accessing the portion of the app they are requesting. See https://github.com/Azure-Samples/active-directory-dotnet-webapp-roleclaims for a sample app demonstrating the approach.
Related
I am stumped trying to find a similar idea on how we can achieve this.
We are currently using a model-driven power app/Dataverse to house school applications. Once an application is submitted, our representatives will begin updating the application record "Application Status" custom field as they are going through the various steps.
Our partner wants to create a external website (just simple HTML/CSS/JavaScript) to display an application lookup where applicants can type in their application ID or send applicants direct-links to view the status of their application. (example: domain.com/application-status/?appid=1234)
This external, public website would have to connect to our dataverse/power app via the web api to make the request and display it to the applicant searching/viewing the website.
How can this be achieved? All I have read is that the user looking up data will need to have a Microsoft account and authenticated in our environment to view the data.
Can someone point me in the right direct on how to get this done (article or existing thread). Your help is highly appreciated.
This is normally being handled by the use of a PowerPlatform Portal.
Portals are designed to allow interactions with B2B/B2C.
This is, however, a hefty price tag.
Another way is to make your website use Rest API calls to your Dataverse tables.
To enable these, you need to create a client application registration in Azure and add this application user in your environment as an application user. Once registered, assign the appropriate rights(Sysadmin, Syscustomizer, whatever you want) and you can access your environment in two steps:
Generate an access token based on the scope of your environment, client id, and client secret.
Use the access token your application user has given to do your CRUD operations.
I have a single realm with 3 single-page applications and a shared backend. I want to restrict the access to one of the SPAs so that users without a specific role can't log in.
But once you create a user in the realm, he can log in to every SPA client. I can restrict the endpoints of the backend but I don't want to programmatically reject the user in the specific SPA but automatically on the login page.
I tried to use client roles which don't seem to have an effect in this case. The only solution I have found so far is to create separate realms which I think is conceptually the correct way but unfortunately brings up some practical issues, e.g. the administrators of one realm must be able to manage (CRUD) users of another realm which seems fairly unintuitive.
users without a specific role can't log in - it isn't good requirement. How system will known if user has a specific role without log in (authentication)? Keycloak provides Open ID Connect SSO protocol, which is designated for authentication. After successful OIDC authentication is token generated, which may contains also user role. So only then authorization can be applied. So let's change requirement to: users without a specific role can't access SPA, which better fits into OIDC concept.
The mature OIDC SPA libraries offer authorization guard (name can differs, it is some kind of post login function), where authorization can be implemented. Authorization requires to have a specific role in the token usually, otherwise user is redirected to the custom route, e.g./unauthorized. That's the page, where you can say a reason for denying access. Common use case is also customization of the app based on the user roles. For example users with admin role will see more items in the menu than standard users - that's also kind of authorization. Random example of SPA library with authorization guard (I'm not saying that's a best implementation) - https://github.com/damienbod/angular-auth-oidc-client/issues/441
Keep in mind that SPA is not "secure" - user may tamper code/data in the browser, so in theory user may skip any authorization in the browser. He may get access to SPA, so it's is important to have proper authorization also on the backend (API) side. Attacker may have an access to SPA, but it will be useless if API denies his requests.
BTW: You can find hackish advices on the internet how to add authorization to the Keycloak client with custom scripting (e.g. custom scripted mapper, which will test role presence). That is terrible architecture approach - it is solving authorization in the authentication process. It won't be clear why user can't log in - if it is because credentials are wrong or because something requires some role in the authentication process.
You should indeed not create multiple realms, since that is besides the point of SSO systems. Two approaches are possible in your - presumably - OAuth 2.0 based setup:
restrict access at the so-called Resource Server i.e your backend
use a per-SPA "scope" for each SPA that is sent in the authentication request
The first is architecturally sound but perhaps less preferred in some use cases as you seem to indicate. The second approach is something that OAuth 2.0 scopes were designed for. However, due to the nature of SPAs it is considered less secure since easier to spoof.
I was able to restrict users access to application using following approach:
I've created to clients in my default realm (master) i called my clients test_client1 and test_client2 both of them are OIDC clients with confidential access by secret
I've created a role for each of them, i.e. i have role test_client1_login_role for test_client1 and test_client2_login_role for test_client2.
I've created a two users - user1 and user2 and assign them to client 1 and client2 role. But to restrict access to client1 i have to delete default roles:
That did the trick, when i am logging with user2 i see test_client2 and not test_client1 as available application:
But i did n't delete roles from user1 and therefore i could see both clients when i am log in with user1:
Therefore you should use different clients for your applications, assign to each of a client specific role and remove from users default roles and add one releted to specific application.
I want to allow users of a SaaS based, asp.net MVC, Multi-tenant DB to login using their social media credentials (FB, TW, G+, etc).
In addition to the social media account validation, how can we determine which tenant or users within a tenant in the DB to validate against? I presume some flavor of Asp.Net Identity should be used to bridge the gap??
I have implemented a custom OAuth server that inturn handles the pluggability of the various social media login modes via OWIN middlewares.
However, when you wanted to have a simplified approach, you can choose to go with Windows Azure Access Control service which can enable you to identify the tenant via their URI.
In that case, you can infer the tenant name or tenant unique value from the URI [like a subdomain part] of the URI.Host.
You may refer here / here / here.
In case you wanted to build your own model, you will have to capture the tenant information via either a unique URI from where the tenant comes from or from getting a tenant unique value from the UI or as a query string from a URI [Rare & least secure case].
The points worth pondering upon will be
Time
Cost [Azure does not come for free]
Customization aspects
Please share your thoughts on the points above.
Context:
We have a monster ASP.NET MVC 5/Framework 4.5 application that is planned to be divided in several others, so each new application will deal with a specific business domain instead of many. All those applications together will provide the same functionalities and services that are provided today by the existing single application.
We plan to use our own OAuth server to provide authentication and authorization for all the new smaller applications, so the very same users that use the current large application will have the same rights in the same functionality.
Currently we use Windows Authentication mixed with a secondary custom structure to establish what a certain user can do. We have our own role provider to generate the roles assigned to the users. When a certain controller action asks for the list of roles af a certain user, our role provider search in our custom structure and provide those roles, following specific business rules that make sense in our application.
We understand that the same rules that establish the set of the roles assigned to a certain user will be moved to our OAuth server.
We understand that the role-based security will be replaced by a claim-based security.
We understand that we will stop testing for roles and start testing for claims.
We understand that the first step of this refactoring should be add external authentication in our current large application and then start to break it into parts so we will have our new ecosystem.
Question:
How to change my current large application so it authenticate and authorize requests by using the new OAuth server instead by itself?
Note:
I´ve read a lot of blog posts but so far I couldn´t find a simple code sample that shows me what to do to instruct my application to go for an authentication/authorization token in my OAuth server and use it to grant or deny the access to a given controller action.
I setup and MVC 4 application and added authentication against our Azure AD server as outlined here: http://msdn.microsoft.com/en-us/library/windowsazure/dn151790.aspx
Authentication works as expected. However, I'm not getting any roles back by default. There should be several AD groups created and I would like to use them to role restrict the application via the [Authorize] attribute in MVC.
I can't really find a good place to even start figuring this out. Can anyone give me an outline or point me to a good tutorial?
I should mention that I'm not the administrator for our Azure account, so I need to be able to tell our admin what to do if any setup is required on that side.
First, tokens returned by Azure AD do not currently contain claims for roles or groups, so you need to get them from the Graph API. Second, roles in Azure AD that are returned by the Graph API are not necessarily intended for use in an ISV/LoB app, and in general you should use security groups for authorization instead. To perform authorization, you should use the checkMemberGroups or getMemberGroups operations in the Graph API, which are transitive and valid for this purpose.
If you check out the following resources in order, I think your questions will be answered. You'll learn how to authenticate to the Graph, call it, and configure your application to use the result of the group operations to perform authorization:
Using the Graph API to Query Windows Azure AD -- This is the second walkthrough to complete now that you've done the web SSO one.
Authorization with Windows Azure Active Directory
MVC Sample App for Azure AD Graph
Blog post describing checkMemberGroups and getMemberGroups
How do I get role and group membership claims for users signing in via Windows Azure AD? -- This one is out of date in regards to the methodology for authentication and the UI for managing users/groups, but it's still useful. Pay special attention to the section on the custom ClaimsAuthenticationManager, which gives you an idea of how to inject role/group data into the ClaimsPrincipal object early so that it can be used in the [Authorize] attribute or other authorization logic.
Sean answer is a bit outdated. You can now configure Azure AD so it will include groups or roles inside JWT token so it will be included into ClaimsPrincipal.Current.Claims so standard [Authorize(Roles = "yourRoleName")] attribute will work.
Here is introduction post. Which basically says you have two options:
Use groups claim - you need to change groupMembershipClaims value in app manifest and later in application you can check for ClaimsPrincipal.Current.FindFirst("groups").Value to see in what group user is (you only get group id). You can write you own Authorize attribute that use this. more info
Define roles for you application and then use normal code for testing if user is in role:
[PrincipalPermission(SecurityAction.Demand, Role = “yourRoleName”)]
[Authorize(Roles = “yourRoleName”)]
if (ClaimsPrincipal.Current.IsInRole(“yourRoleName”)) { //do something }
You need to edit roles in you app's manifest.
More info here and here. Values needed to be set in manifest are described here
What is really strange is that you can't assign more than one role to group from Azure web page. You need to use azure graph api for this.
If you can't see Users and Groups tab in Azure portal you probably need Azure AD Basic or Premium edition. If you are working on free azure subscription you can use free Azure AD Premium trial to test stuff.