Microsoft 365 Community Identity platform, 20 Oct 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: App Roles to manage authorization in your application-October2020

Description

This month's community call covered App Roles to manage authorization in your application including what is Authentication and Authorization, why Authorization is important, Groups vs Roles, AppRole - Users/Groups and
AppRoles for single tenant and multi-tenant apps.
Speakers: Jeevan Desarda, Saurabh Madan

Get started with App Roles https://aka.ms/AAa11te

Stay connected
Twitter https://twitter.com/microsoft365dev
Blogs https://aka.ms/M365DevBlog

A

My name is stephen: salazar, I'm a program manager in the microsoft identity, platform team and today we have with us two great program: managers from the microsoft identity platform team as well, given tesara and saurabh madan and they're gonna talk to us about how to use app roles in your applications to manage authorization for them and some of the latest and greatest work that we're doing in that regard before they get started. I just want to go over some really quick logistics.

A

I just want to mention that this is a public call, so we are recording this call and we plan on publishing this call later in a youtube channel.

A

You can find it in a url called aka.ms, slash m365 that youtube. It's also great, if you can follow us in a couple of yammer channels at microsoft, 365 dev or at azure id.

A

So these type of calls happen once a month, so every three every third thursday of the month, and you can always attend this call. I we're gonna share a link here where you can add the calls to your calendar if you like.

A

So another thing, it'll be great to hear feedback from you in terms of how this call went and also, if you have any suggestions for topics that you would like us to cover uh anything that you'd like to learn from us, it's always great to hear from you so that we get content that matches your needs.

A

A survey that you can use to just give us feedback, how the call went in terms of the topic and also you have ideas for future topics that we should cover, but uh without further ado, because I know jivan and surab have quite a bit of content to go, I'm going to give it to them so that they can do the introductions and and then get started. And so thank you. Everyone.

B

Thank you. Let me introduce myself, I'm jeevan lisida, I'm a senior program manager in azure, active directory and my particular team actually works on the integrations for different sas applications with the juradi, particularly on single sign-on and user provisioning, and we list these applications into the app gallery.

B

Along with that, we also closely work with enterprise customers to configure and deploy the applications. As we are part of the customer experience team, we understand our customer scenarios and help them deploy these particular applications. So that's my particular core role and I have served up with me over here. Sarah, can you please introduce yourself.

C

Yeah sure, uh hey everyone, I'm sarmadan program manager here in the identity, division and my team that I'm part of we work on uh app permissions, consent experiences and uh I particularly look into the credentials uh space of applications, and uh today we're gonna be talking about app roles.

B

Before I go to the agenda, I just want to set the right expectation over here. So our goal over here is to tell you about everything, about the authorization and application roles and and groups, and how you actually should do the application roles. uh Or how do you actually do authorization using application roles or groups? The idea is to present that at a higher level, like think more about ten thousand feet overview uh strategic more way. I know when it comes to implementation.

B

You all are developers and you all can figure it out how to do it, and there is enough amount of documentation you have, but let's look at that particular part more strategically, so for in the first we will go and look at authentication and authorization.

B

What's the difference and what's happening over there, why authorization is getting so important nowadays and then how do you actually achieve that authorization when it comes to azure id for applications, so it might be, it can be done using groups or it can be done using roles when we are talking particularly about roles. There is a particular app roles are possible for different objects.

B

Like users in groups or applications, and we will see that there is also a new user interface we are coming up with, so we will showcase that particular interface to you and then from there. We will go about single tenant and multi-tenant apps. So it's a scenario where you are a line of business developer for your organization or you are an isv developer. Who is developing application for our multiple customers?

B

Then? How do you consider authorization in that case and before you start actually coding? Let's look at some watches with what what is there and then we can actually summarize our learnings over there, so you can actually go and start off the actual implementation of it. So that's how we are looking at our agenda today.

B

So first, when we talk about authentication, I know for years uh our customers are using single sign-on and they are doing idp based authentication, but that's a real need nowadays because of the covet situation. Everyone is working remote and people still or the users employees, whether it's a partner vendor or customers, everybody actually working remotely and need access to different set of application, because this application hold critical information for our users.

B

So we would like to simplify that sign in and that's where the single sign on and idp based authentication is important. We know this is happening along with idfs 15 20 years back, but now it's like everyone is moving to the cloud idp. So there is a still need, whether it's a line of business app or whether it's a sas app. You still need the single sign-on capabilities, the authorization part right now we are doing.

B

We are seeing a good shift from our customers, where our customers are now actually looking more into the authorization and the authorization basically is to control. Who is doing what into that app more granular control on those critical accounts is important and that's where the business and the it want more visibility. Who is doing what into that particular application?

B

So also, customers would like to improve their business process, for authorization want to achieve some rules around it and that's where the authorization is gaining more popularity and that's what the inclination we do see so from developer perspective.

B

Now we are going to see how do you make that particular possible or why you should do that, particularly so, when we say authorization why it is getting important because think more about situations now, as users are actually using the application from their own laptop their own desktop, or they might be sitting at the grandma's actually house, and they are actually accessing the app it administrator and identity team want to achieve a better security control, and that's why they have to know who is doing what into that app think more about like a business, critical application a customer has, and they wanted to know how admins are logging into that app so that they can secure that particular application differently for administrators versus the normal users.

B

But they can only do that when they have a visibility like who is an admin on that app versus who is the user on that app? And that's: where actually comes more authorization part which need to be managed from the identity provider? So authentication is just implementing single sign-on using open edit connect to earth, but to apply these particular roles. That's where the interest on the business side is more on.

B

How do I achieve this particular granular control on different users or groups so that I should know what they are doing into that app and and that's what the authorization is giving more importance nowadays, I'll just stop over here. If you have any questions, feel free to ask me and saurabh over here and now we can take some time to talk about it and then we'll go further.

B

Okay, let's talk about, uh have you used idp base authorization in your application? So please let us know by typing uh your answer, like I don't know, I'm not a developer over here, but you're more like an architect or or just the admin so you'd like to achieve it or if you say yes, sometimes I use it or I use it always or I never use this particular authorization. I just implement the single sign on using ncl or open id connect to earth and I'm good over here.

B

I do see that a lot of b over here so sometimes I use it, and I do see there are a few c's also which is really nice, and I do cd and I'm literally getting worried about. But okay no worries, I think after this session, I think you will all uh all feel good about. At least you have understood the concepts and now you can be able to easily decide which way I wanted to go good. Thank you.

B

Thanks for putting all those answers and I'll wait for five more seconds to see if somebody else wanted your type.

C

Okay, yeah, even there was a question up in the chat about uh who's. Doing what is authentication, so I just just wanted to clarify one thing here: uh identifying who you are is authentication and what you can do and what uh what you're authorized to do is the authorization part of this is how you can differentiate and look at these things.

B

Yes and that's what I gave you the example of the admin versus the normal user, so what you can do into that app is also important and based on that customers want to apply the security controls and that's where the authorization part is important. So basically, is the role. What you carry into that particular app is the authorization and that's where it's important to understand, but yeah thanks.

B

I have got enough amount of responses, so, let's move forward so now, when you think about azure active directory, there are two options over here. You can use groups for authorization or you can use rules for authorization, but the question is: where should I begin from so we are going to talk about both these particular scenarios uh and then we will see it's like okay, what is actually suitable in your app and what are the significant difference between two? So, let's start with particular group part: are you using group information into the application?

B

So this is a question two: have you ever used the groups into your application uh for authorization, purpose or okay? So sometimes you use it. We need the groups or agility rules, work with digitally b2c.

B

Yes, I'll answer that question also. I know there are people typing. So, yes, the concept still works in azure id and azure ddb2c. So either it's a group or roles. It works on both the ends. So yes, so whatever we are talking is going to be also applicable into the v2c 10, and so, if you have, if you're a b2c developer, it's still valid for that all azure. The roles do not work with ad groups. Yes I'll I'll talk about it in little detail, just wait for a few more minutes.

B

Okay! So let's talk about the group part of it first. So when you are using groups for authorization, there are different types of groups in the organization, so basically consider on-premise groups like security groups and distribution groups which lot of our enterprise customers are actually syncing. These groups from on premise, active directory to azure, active directory and then also cloud customers create all like users can create office groups.

B

You can create azure id groups, there are dynamic groups, you can create based on that role or you can actually write a rule and say if the user is the department. Is sales then create this particular group and all the users into that particular group. So this is, these are the different types of groups, but when you are writing an application, you have to plan for all types of groups. You can't just say it's like okay, it's my on premise, group or I'll rely on the cloud groups.

B

The one of the major thing with azure active directory is the group. Names are not immutable. Values, non-invitable values the names, particularly so what it means is you can create suppose the office group or the cloud group with the same name again and again, it's pretty much possible because we don't check for the uniqueness of the group name in the on-premise world. There is on-premise sam account names which you can always consider as unique, but that is not the same case with the cloud troops or which are agility groups.

B

So that's one of the thing and that's why we feel that passing the group names. In the token, like all the group names, including cloud troops, is not very secure solution, because in this case a user can just create a group and part of that particular group or owner of that group and then just pass that information in the token and the application will do authorization based on the value what it receives in the token. So that's why it is more riskier and that's why we suggest to use group ids.

B

But then, when you use group ids, they are not like human readable. So that means it's like a great value or a 36 character, uh alphanumeric value with which is like hard to understand for mapping those particular information into the roles for your app. So you need to do that.

B

Mapping which some customers really don't like it, because they don't know by looking at this group id what it means right, because they are not human readable and a few of the things you don't need all the groups in the token so consider, if I'm, the user, who is part of 200 particular group, as you ready, will send that information in the token- and you will still not able to see all that but or you will be able to see that all that group information, but that's not all usable uh in that term, so the group filtering capability in azure id is still not available.

B

So there is a partial you can say is available through the applications assigned to the group, but that might not always like be helpful as you need it, and if there are more particular group in the token there is always a token bloat possibility. So I've seen this with few customers where the token bloat happens, and then then you cannot actually be able to pass or to get the response event. So that's like one of the biggest thing I'll just little bit over here. uh I think there are a lot of questions over here.

B

uh We use it when coming from sharepoint online. Yes, I have seen the sharepoint scenario where you need this particular group information, but that's a group ids 80 groups, don't always work for certain types of authorization, for example, when attribute based authorization is needed. Yes, for a back purposes. Yes, the ad groups is not always suitable solution. I agree with that. What is the demand difference between pass-through authentication and password asking? Oh, I think that's not a question over here. It's particularly you are asking about authentication, so there is a good amount of documentation.

B

We wrote for pass through earth and password hashing, so I suggest you to look at that authorization with authorizing with idp when utilizing multi-tenant art is my primary issue that drivers that drives as needed to move the application based off okay, so multi-tenant. So we are going to talk about singleton multi-tenant into that. I will try to answer your question. There is also the constraint that dynamic groups do not support multi-values. Yes, that's true, and we will see what is the multi-valued. Actually, you can able to do it.

B

uh One of the biggest challenge with the group is the limitation of number of groups which can be passed in the token yes. Today we have a limit for 150 particular group ids. In the token, if there are more than that, then there is a query which is getting passed and you need to invoke that graph particular query to retrieve the information.

B

So that's absolutely true. This has been also documented b2c. We were advised not to use group but use custom claims to handle authorization instead, but this changes now uh so it depends on your scenario.

B

Sometimes in b2c, using groups is not a very good control, but you can actually in b2c, allows lot of customization of the claims you can also able to do that. It's depends on the approach. But again, if you are using groups, you should be using or you will be using group ids, particularly if you are okay to use the group is, then you should do that.

B

um Are you going to use more bandwidth for a token rather than the payload?

B

Yes, it will use more bandwidth for a token, uh because this goes into the body, as you already actually post, always post the response using post binding. So that's where the response goes into the body and the body always has a limit based on the browser, so some browser like 2 kb, is a limit. So if your response was beyond that, the body will not able to accommodate so many things so that open bloat happens how to change office groups to dynamic groups.

B

That's not the topic too. I think I suggest you to submit a stack, workflow question for it where I'll be happy to answer that. uh Yes, we are going to talk about app, assign teams or groups. Okay, let's move forward. There are a lot of questions. Okay, so now, when we look at for approvals, so the difference between app roles is, you can actually apply app role for every app in azure id.

B

That means any app in azure id, whether it's a saml app added from the gallery or non gallery app or whether it's app registered using app registration. You can still able to configure app roles for it. Saurabh is going to talk about the user interface and graph apn manifest option for that. How do you configure that? So you will be able to see that over there, one of the good thing on app roles, it's more! It's about the uh it's! The claim is in the human readable format.

B

That means if there is a specific role which you are actually putting, it can be configured on the app and it can be sent in the token which can be readable, one of the biggest difference. What you see when we are comparing with groups is based on the groups. You have to do group to role mapping into the app versus when you are using app role as a feature. In that case, customer configure the role based on the what you actually have as roles configured into the app so think more about.

B

There is an app you are developing where an uh signing is e-signature app, and I have a three particular roles, so uh admin approver and a user as a role. So these are my rules which are being created into my app. I can replicate the same in using app roles in azure id and then just do the mapping of that particular user and the app roles. So that's the biggest difference.

B

That means your roles stays the same and you get that information into the idp for the admin to map with the groups, whereas, if you're using groups, then the group's ids are sent- and you have to do that- mapping into the app like which groups map to which particular role. So that's the significant difference between two in saml. We do provide a customization of the claim where you can say my role particular claim looks at whether role member of or whatever it is.

B

You would like to call it as and you can still able to do that, configuration and send it in the token, but into the open id connect to what you can't do that app roles in the claims are multi-valued attributes.

B

If the user is part of multiple groups, then he can able to receive multiple roles associated with the groups and that's where the actual. You can able to see those particular roles, and I have a quick example for you to show on this. I have my sample app and called azure ready, saml toolkit app and in this particular app I configured different roles, so here you can able to see. I have a finance group which is in approver versus my hr is an admin and all everything users are part of the reader.

B

If I, as a user like jeevan, is part of multiple particular groups, I do get multiple roles associated with it and when I actually use this app in the token I can able to see that this how this particular roles are getting passed in the in the token, so I can test this application and say sign in as current user and when I do that, okay and I can able to use- and I can download my saml response and show you over here and you can able to see.

B

Okay, let me show you the claim configuration I have done, which is app role, member and then user dot assign roles is the key. I used it so here when I go into the token you can see app roll member as a claim name, and these are multi-valued attributes that I'm in admin and I'm also an approver so based on my particular user.

B

It actually gets that particular all the rules and they are shown over here, but that's how it works. So this is possible into the saml. If you're using jwt, then you will see role as a claim and then you will able to see the area of the particular values which you can able to process it. Coming back to our particular thing, I would like now to hand it over to sarah, so that saurop can talk about particular app roles for different objects, and how do we do that? Using a new interface yeah.

C

So app roles can be configured and defined for two or three different possibilities. One you can do app create define app roles that are assignable to users or groups which you can do through the enterprise apps in case you're. It's going through a user assignment for uh for application. uh The other one is uh the other scenarios. You can configure app roles to be assigned only to applications. So in in a scenario where a client app calls an api, uh you can.

C

You can assign app roles for that scenario and that that shows up in the access token, in the roles claim of the access token. So this is. This is particularly useful if you have automation scenarios where you are trying to automate things and- and you just have like application specific uh roles and you you're trying to build automation based off of that. So that's that's uh one of the particular things.

C

The next thing that I want to show here is before I jump into the interface one of the major problems with the app role definition today uh that you know we got a lot of feedback on. Is it's hard to edit the manifest? And it's hard to define app roles in the manifest for for a lot of reasons, uh one it requires it requires json editing, uh so you have to get into the manifest edit that json either export the manifest out and edit.

C

The json then come back and paste everything back in and there's like all sorts of problems that can happen like the fat, fingering, accidental, key strokes or you know, copy pasting errors there and then the the other problem is.

C

If you look in the app manifest today for every apple that you create, you need to provide a unique good for that app role and that's something that the user or the app owner or the diamond needs to generate that good and then and then add that in so that's an extra added step, which is you know, is not desired so to solve all those problems.

C

What we have done, uh what what we've done is created this app roles, blade in the app registrations and what that provides is basically just a representation of whatever is in the manifest. So an apple definition is is represented in this ux here. So you can see a display name description, the allowed member types value id and the state whether it's enabled or disabled, and then, if uh actually before, I move forward quick question. Is the navigation name descriptive of the feature, the the blade name? That is.

B

C

B

Setup on that, so the display name should be sought alphabetically, so that people can able to see the approvals display name. You.

A

B

C

Yeah feedback feedback taken, and uh I I see that the answer to this is yes and which is I'm so glad to hear, because we went back and forth on this on what to and how to name this blade. So I'm glad to hear that okay, custom app rules, that's one option right. I think so. The majority here is a and thank you so the create and edit apple experience once you click on the button to add app roles again, the same properties that you would add in the manifest.

C

Now you have a ui for that. A lot of member types here, particularly, is you can pick either user groups or application, as you would do in the manifest or you could pick for both, which adds the allowed member types as users and application in that collection.

C

The value is, has all the validations for uh you know, disallowing any spaces, or you know special characters that you would otherwise not be uh would not put in the manifest. So you get a direct feedback even before you hit save it, validates the the field here and then, like you know, the description enable is pretty self-explanatory.

C

um Something I want to call out here is if you have used app rules or if uh or if you, if you created a few new app roles and then went back and then uh kind of forgot how it was done or if you had somebody new on the team, uh we added this context fly out for describing like a quick two-liner on how to add app roles in these two scenarios that I just described like for either adding it for uh users and groups and applications, and this was particularly important because the assignment aspect of the app role is in two different places.

C

One is in the enterprise app and the other one is uh you'd have to go through api permissions if you were doing a app-only permissions, uh so that's why we not like to call it out and the other.

C

The other aspect is like: if you are an isv and just creating an app that uh you know if your tenant admin, where the app is provisioned needs to add app roles specific to their tenant, then they would also get the same level of understanding on how how do they start assigning these versus getting confused with the definition aspect of it?

C

Deletion goes to the same rigor as what it would do in the app manifest. So if you were trying to delete an app role, it would require you to first disable it, and then you would go and be able to delete that. The one thing here is once you do, disable the app role deletion has all these red, so-called red flags that stop you and warn you from from proceeding. If uh make sure that you're doing the right thing.

C

uh The one thing that I do want to call out, which more than likely will change, is removing the assignment part. Here it doesn't really remove the assignment. It's just that those app roles and the logic in the backing application in the code will not.

C

It will not work since the user or the application will not have the role in their uh claim in the role claim, so the assignment doesn't doesn't go away, but uh the reason we want to call this out is like, if you go back in the ui, create the apple with the same value which is uh over here. It really wouldn't work, because uh the good in the back end would have changed so you you could be under the assumption that you could delete an apple and then go back and recreate it.

C

But in the back end your your your goods have changed. So that's something uh important to know.

B

And, and just to uh mention over here on this particular slide about deletion- part that we we don't check the whether you have done the assignment or not. So if you delete the role it's and you have assigned that particular role to different groups, they will not receive that. In the token, so there will be an effect on that. You need to consider that uh before you are deleting and that's why the disable option is provided and then actually delete.

B

So that's why we clearly call out that it is going to have a larger effect on it. If you are, if you've done already assignment yeah.

A

And this is that.

B

Largely impact on the multi-tenant app so which I'll talk in few minutes later right.

C

And, and just before I move away, uh thank you jeevan. That was a great call out one more thing before we move away from this screen and get into the apis.

C

This, this ui will start to light up in the next uh few days or so, and we were just working out a few last minute hiccups, but just want to make sure that everything is ready to go, and you should start to see this show up in the next uh next few days.

C

I am seeing questions fly by and I think the last one is what apple will applaud creation work for users who have owner rights on the app? Yes, it will so any anybody who has a global administrator, app admin, cloud cloud, app admin or an application, app owner role. They will be able to support b2b support obo flow as an api developer. This is much required.

C

I don't believe b2c supports that and I don't know jeevan. I don't know if you have more information.

B

Yeah, but I suggest again to put that on stack workflow, it's about the authentication, what you are trying to and check um I'll prefer to get that answer from the right product team directly over there rather than over. Here.

C

Awesome, uh I think uh the best thing to enable the app role yep. Thank you, uh okay. So moving on to the app.

B

Just to answer one more question: I think there are a lot of b2c, but b2c does support approvals, so even in b2c you can actually in the manifest also you can able to create the roles or using the apis, and you can able to use it in the same way. When you are assigning that particular group uh or a user to the application you can able to assign different roles. I personally tested this. Yes, it works.

B

C

Max number of app roles still is the same uh and again you're running into that limit. There are other options that that should be considered, uh but yeah, the there's uh that upper limit hasn't changed this information.

C

We are planning to do a blog announcement and once the it'll be appropriate like when the deployment is finished and when the blade is live, it'll be better if you, if you can share at that time since there will be something for folks to go back to the portal and check it out all right, so I am going to move forward uh so regarding the app role apis and the manifest.

C

So if you see uh the screenshot on the right, this is currently how app roles show up in the app manifest, and this is where application owners or tenant admins or anybody who has access to modify the application, would go here and add their app roles.

C

The one thing to uh to call out here is like, if you're looking at the origin value, this is the application is, is where the app role was initially defined. You can define app roles as a tenant admin on the service principle as well, and that's where this this value would be different so, but for most of the app rules which get defined at the application object level. uh You would see the origin value as application.

C

uh We have uh microsoft graph apis for getting the information on app roles and you can do a call to uh wac application. My graph microsoft.com applications and get a list of all the app roles or you can go to the service principle and and get the application rules on the service principle as well, and then there's a documentation link that will be shared as part of this deck.

C

Even that is it back over to you.

B

Thank you. So when we are talking about the app roles for single tenant applications, so there might there are multi-tenant. There are two basically scenarios we are talking about. That means again, you are, you might be a line of business application developer, where you are developing application for your own organization and in that particular case, your scope of the application is very limited to your particular tenant and the users into that tenant. That does include b2b users.

B

I just want to make sure that you are aware that, if you add suppose you are a contest organization and you are adding fabriccam user as a b2b users into that tenant, you can still able to assign different roles to that particular user or you can create a group say fabricam users as a group, and I can add fabrikam users into that group, and I can able to assign a role to that particular group.

B

It's the same way behaves as it behaves for your employees, so you can actually uh configure the app roles on the application object and then you can say it can be configured for users or groups or applications, as actually serup just actually shown that to us for multi-talent apps. Now I would like to call out it's a little. um uh You need to think little bit deeper on this. So when you are developing a multi-tenant application, it's for all azure active directory, tenants. That means scope of your application is very wide.

B

That means anybody as a azure active directory customer can consent to your application, and then they will get a service principle into the customers tenant and you as an we hold. The service principle object and the application object in in your master tenant. So you can configure the app roles for your application object over there and when your customer actually cons consent for an app, they will receive the service principle, but they will also receive the all the particular rules associated with your app and they are coming from application object.

B

So it's important to understand that and whenever you are making a changes over there, it's directly going to affect it. So let me show you uh this is my microsoft.com tenant and I have a multi-tenant application over here called azurity app gallery information and I created three different particular roles over here. You can see it's a member role, gta and admin. There are three different roles. I have it, so these are the specific roles created for my particular app, and this is a multi turret application. That means the scope of this application.

B

Is customers can consent for this particular app? And you can see this is a multi-talent app so now, when my actually customer, so I have another test tenant from where I can able to test this and I'll show you. So this is my test net, which is given at simplytest.net and uh let's search for that particular app.

B

This is already uh app gallery information, so this is a consented app, so I have consented this particular app from my simply testing and to that microsoft the main application is hosted in the content. So now, when I'm actually looking into users and groups, you can able to see, I select a user, and I click edit- and I do see all three roles over here, so that these three particular roles are coming directly from that particular app, which is, I have consented for.

B

So in this particular case, I think when you are modifying the roles you have to be very cautious, because all the customers will immediately receive the change on their side. As you update the role on your master app and then they can able to select and use it. So I think this is what you need to define first, when you're actually creating a multi-tenant app at that time. You have to think about it like how my customers are going to get these roles and what roles they can use it.

B

If you remove the rules, it's going to get immediately affected to all the customers, so uh you're not able to see that token, and the assignment is not like uh immediately. That will assignment will show saying that the the role is gone now, which you have previously used and that's how the difference is so. I can now able to see that I have assigned this particular role to a user, so that's the difference between single tenant and multi-tenant, app so think, twice about modifying it or deleting it.

B

Adding should not be the issue because you're just adding more roles over there and you can easily able to pass these particular new roles to your customers and that's where your customers will receive it and then you can use it in the token for authorization. Part of it so also shown you. We do have an api for that which says on the service principles. What are the different app roles and you can able to see the roles I created for the app and they are originating from the application object.

B

Similarly, I can go into the application object also, and I can able to see it from there saying that, which particular roles have been created which are app roles are associated, so I can able to see that from the application object. Also. So all these particular graph api queries are available and we have a documentation which talks about. How do you do the app roles and the app role assignment when you are using this particular assignment to user or groups or applications? There is also an safe rate api for that.

B

I think somebody in the question the chat ask me this question, so I just want to call out there is a separate api for approval assignment and there is a separate api for app roles.

B

Okay, so now, uh when we look at the gotchas before you start, so I think app roles is beta suited for core screen authorization. That means, ideally, although we have a limit of 1200 app roles, is the limit on the object. So, ideally it's near to 1200, it's not like exact 1200, but it is the storage limit on the object we have.

B

So, as you are putting more particular application roles, your particular object limit is getting reached and that's where you will start facing the issue, but I have seen lot of customers struggle at the limit of 1200. So that's why we call this out, as 1200 is 11. note, that april value is limited to 255 characters. That means you cannot actually have a bigger than 250 character. 55. Previously this limit was 130 ah six months back. We modified this to 255 characters, msm access. In some cases you will see this role, but that's a default role.

B

If you add the application from the gallery, then you will see this role, so please don't delete that that will be used in the app gallery in that particular way. There are some limitations on. You cannot use special characters like space and there's all that validation is there into the ui now so I hope like. uh If you need like particularly space, then you will not able to achieve that, and there are a few some special characters. Even we don't allow that. But all that actually check is there on the ui.

B

uh You can consume the claim that value in the jwt or saml claim directly. So you can able to do authorization and values in the claims are multi-valued. So when I'm thinking saying multivalued, so I've shown you that in the sample how it appears for particular jwt, it becomes an array and then you can able to see it to get multiple value of users. This is a very important aspect, because the group assigned to the application is a premium feature. That means it requires at least security premium one.

B

You need to think about the rules, because the uh how multiple you, how the same user can get multiple roles. Basically user is part of multiple groups, say mg1 and part of group a and group b, and you are assigning role a and role b to the respective groups. Then I'll get both these particular roles, but if I don't have azurity premium, I cannot actually assign these particular groups to the application, and that way I cannot actually able to get multiple roles.

B

That means you can only assign user objects to the app and then you can only able to assign one particular role. So you have to think very thoroughly about your licensing model for your customers. If they have azurity premium, then they can able to get assigned multiple roles to the users and then you can receive them in the token. Otherwise they will only always have like one particular role if they assign directly user to the app.

B

So that's like you have to uh note, and in summary, what we have seen is uh we suggest that app roles is preferred over groups, because it's a cleaner way to get. You know, create the roles and send that role in the claim.

B

uh Remember about licensing, because if you develop that way- and you are expecting multiple roles and if your customer does not have azure data premium, then it will be an situation over there, because customer might not actually separately buy agility premium for your app or, if your app is, that important that they might be. But that should be a consideration.

B

So there is also now a ui and epa for configuration. As I said in the chat window, ui is going to come in few more weeks. I think, and it will allow you to create the roles and manage the roles very easily. If you change the app roles for multi-tenant apps, all your customers are going to immediately receive it so making changes. It is important that you consider that, and you can also con use this particular after all, in the automation, particularly on the service principles.

B

uh We suggest don't add too many rules. Otherwise, it's like again 1200 is the limit. As I said, and I've seen in some cases the token load happens. So don't do that for cool screen authorization so uh think more about like 20 30 might be good enough, but you can go larger if you need to, but should not be like 1200.

B

So that's what actually we suggest uh that's how it should be. That's that's what it from our side. I think we still have like five more minutes or so so I'll open the floor for questions so I'll prefer you come out of mute and then we can talk about the questions.

C

There's a question in chat, which uh I I think we should answer here for the benefit of everybody else's thing like the question: uh sahil had about roles versus permissions and and what how are these? How are these different.

B

Okay, so the app role information goes into the token and then you can actually see a lot of times. I have seen the apps actually inside the app. You have a permission model saying that this is my permission, and this is the role for it and you just map that, from the token value, like the the value which you received in the token to that particular role, so role to permission mapping is still happens into your app.

B

You just validate from the token that what particular role this user carries and then you actually do that over there in your app, so that the user will get the right role.

B

So, while you process the token, you should be actually assigning that particular role or authorization, you should do it in your app and that there is a question on this specific license: p1 or p2. uh Yes, at least p1 is required if they have p2 still works, but at least p1 is required.

B

Can approach be used to granulize graph api permission, especially high privilege api permission? You can do that, but we don't recommend to do it like, especially for high privilege api. You use the app rules rather than you should use the r back role based access control. We do have a custom roles, even in app registration, even in enterprise app, so we suggest customers to create that um as a developer. I think you should think more about giving an ability for customers to create a role-based access control on that, rather than use in the automation.

B

If you would like to do it that that technically is possible, I'm not saying it's not possible. Okay, any other use cases where you'd not recommend to use approvals. um As I said like. If you would like to go fine grain where it says like I have thousands of rules and customization, then we say just don't use it in that way, because it's too much amount of operational for our administrators.

B

It should be ideally very, of course, like you can say, 10 rolls 20 rolls. Then that is much more suitable, but in that case I'll say just do it in that way, for asp.net do app role gets mapped to roles as they just claims on the user objects for asp.net. You can use the square brackets and define the role and enable to process that particular role from the user object, so you you can able to use it in that way.

B

uh Okay, russell has a feedback on the link, is not working so I'll. Give that feedback to stephen stephen will look into that and we'll fix it. Have I missed any other? uh What okay? What have you seen happen at around 1200 rolls? Okay, so what happens around 200 rolls? Is you will not able to edit the existing roles or if you will not able to delete the roles or modify the rules?

B

So that's the issue happens the work around on that you can use graph api and remove certain roles through the apis and then that works and I am hoping with the new ui. That is also going to be possible because you can easily able to disable and delete the roles as needed, but you will not able to update or add more roles over there and that's the major situation which will happen so around 1200 roles. You will feel you will. You will see that situation.

B

I have seen this for a few customers where they struggle on that result. You can able to delete and uh disable the roles, but you will not able to modify or add more roles.

B

uh Okay are the app roles in customer tenant, build over the initial consent leak and then the flow is for add remote. Subsequently, yes, you are right. So when customer actually consent for your app, they will get the default role.

B

What you set so consider, if you just add one particular role for your app by default, they'll, get that if you have more than one particular role, then the the first role they will get that uh generally, it is msim access which is default access role, and then the customer can choose saying that I, when I'm assigning this application to other users and groups, I have to choose a specific role. So that's how it works: okay, so, but who assign roles to customers?

B

Okay, so the role assignment is always up to the customer and the admin, because in the enterprise application in my tenant, as a customer, I decide which particular groups will be assigned to the app and what role they get, whether I'm assigning users or whether I'm assigning groups at that time. The administrator actually selects the right role for it.

B

A

Even we're approaching the end of the hour, I'm not going to stop you, but I just want to thank everyone for joining us today. We really appreciate your taking the time to come here and ask questions and and and give us that that's great. If there's any last uh questions that you want to address you and that's great, otherwise, we can just say bye to our friends.