Granular Authorization in Cloud Apps with OpenFGA hosted on Azure Container Apps
HTML-код
- Опубликовано: 8 фев 2025
- This video introduces authorization concepts. It discusses different approaches to authorization handling and introduces authorization implementation with OpenFGA hosted on Azure Container Apps.
Helpful links:
OpenFGA documentation:
openfga.dev/do...
OpenFGA playground:
play.fga.dev
Azure Container Apps documentation:
learn.microsof...
Gist for Azure Container App creation with OpenFGA:
gist.github.co...
Azure Data Studio for managing PostgreSQL:
azure.microsof...
Hey Daniel, that was compelling demo! I see on your channel you covering tough topics mostly related Microsoft security which in most cases people not willing to talk about %), because they can't describe that on a certain level so everybody can follow. Your videos are very exciting, as a fresh breath and I love watching them straight from start to finish, though need to admit requires some basic strong level of knowledge in auth related stuff.
I definitely give that framework a try!
Could you please clarify a few questions I found confusing from the first look:
- do I understand correctly that ReBAC doesn't replace AzureAD scopes/roles and can be used together as more granular control or it doesn't make sense and it is better to use one or another to keep things less complicated?
- is it worth to use ReBAC taking into account the learning curve, integration and deployment? Maybe there are some "for sure" recommendations
- does it make sense to integrate the framework in small or mid size projects or it is bad criteria and I should rely on use cases primarily?
- considering example with requirement policy, it look not dynamic (I understand this is just an example). I guess if we were to build a document management application, for instance blob storage with different access level based on path and admins manage requirements at runtime, we would mainly use just "check requirements" function to evaluate latest requirements without policies, right?
thank you
Thank you for watching and kind words. I decided to focus on such security/identity topics as I was struggling to find good explanation and helpful materials. I am happy to see that it helps others.
To answer your questions.
- Do I understand correctly that ReBAC doesn't replace AzureAD scopes/roles and can be used together as more granular control or it doesn't make sense and it is better to use one or another to keep things less complicated?
This is correct. In this specific scenario with Azure AD, we can still utilize both authorization types. Azure AD roles would be used to make sure that for instance we can verify whether specific user is Azure AD Global Administrator. To handle more granular control, further in the applications and APIs, you can use ReBAC. Please remember that it is also important to analyze your specific scenario and requirements. For instance, if you decide to use RBAC and check if user is global administrator, this information can be returned in the token (as I presented in the video). You have to be prepared for the situation when user role changes - to react to these changes in real-time if required.
RBAC in Azure AD is more to control access to applications and Azure AD resources. If you want to implement granular authorization model in your custom solution (apps and APIs), approach with Open FGA and ReBAC can be good idea.
- Is it worth to use ReBAC taking into account the learning curve, integration and deployment? Maybe there are some "for sure" recommendations?
I do not want to answer, “it depends”. However, you have to answer few important questions:
1. Do I need to implement granular authorization in my solution based on the requirements?
2. Will there be multiple applications and APIs that need to count on granular authorization data?
3. How complex is your authorization model now based on the requirements?
The truth is that after analyzing the requirements you can make up the decision that having information about the role in the token is enough. Having centralized authorization system can be beneficial from the maintenance perspective. Let me give an example. In the Azure AD you have the concept of “App roles”. You can assign different, custom roles to users in context of specific application. This information lands in the token. In such scenario, you control authorization data from the Azure AD not custom authorization system. You have to make sure that you control user role in context of different applications. It can become challenging when for instance you will need to check “what roles user has in specific applications”. Please keep in mind that roles are assigned in context of each application so you will have to also implement them for API apps.
- Does it make sense to integrate the framework in small or mid size projects or it is bad criteria and I should rely on use cases primarily?
I would not rely on the project size. There can be a situation that project is not big, however the number of authorization scenarios is quite big and there will be multiple relationships in the system. I would rather focus on the complexity of the authorization model, relationships, and how you want to manage authorization data. IT Administrators can be good on administrative tasks on Azure AD but will they handle authorization data maintenance correctly? Maybe it is better to create custom authorization data store and separate it from the Identity Provider (like Azure AD)?
- Considering example with requirement policy, it look not dynamic (I understand this is just an example). I guess if we were to build a document management application, for instance blob storage with different access level based on path and admins manage requirements at runtime, we would mainly use just "check requirements" function to evaluate latest requirements without policies, right?
You are almost correct. Here is the thing. You can dynamically check permissions during the call to access specific document, directly in the endpoint (method responsible for handling requests to access documents).
However, you could also utilize policies as I presented in the example for do it dynamically. You are correct that in my example it is static. You could adjust the code and make it more dynamic and still utilize Policy approach.
I hope my answers will be somehow helpful to you!
@@TechMindFactory pretty descriptive, thank you!
For my work this video was very timely. Thank you so much for the deliberate and focused walk through. Do you have any resources for the kind of service architecture that would support openFGA? I'm currently working on a permission service but haven't settled on a way to expose the language so other services can build up the tuples to ask the right questions of the openFGA service. If you had any resources to share it would be greatly apprecaited. Thanks again!
Thank you so much for watching and kind words! I apologize late reply. When it comes to service architecture, currently I do not have one that I can publicly share but once I have some time I will try to collect the details and create some "demo" architecture to share.
@TechMindFactory Hi Daniel, can you provide some more explanation for the Postgres setup? I do not have much Azure knowledge. I'm following this video and I created the Azure Postgres server and the OpenFGA container app.
1. Do I need to run the migrate command against the Azure Postgres server? If I do, how do I do this?
2. I am checking the log stream for the Azure container app, it says OpenFGA playground has started on localhost. Does that mean OpenFGA is setup correctly with Azure Postgres? I didn't run the migrate command or setup any datastore. Do I need to run those commands?
3. How do I access the playground hosted in Azure?
Thanks!
Hi Daniel. Great Video. I followed your tutorial and I have issues while creating a store. It says "Internal Server Error". Have you faced a similar issue? I have the server and Postgres up and running.
Is the repo used in this video available?
Unfortunately, it is not yet published. I plan to do it and I will let you know then. Thank you for watching.