Given an application that shows objects (e.g. films) according to certain user permissions.
The general permission to show or create objects is implemented as RBAC with roles and permissions.
The specific permission to access an object with certain attributes (e.g. a film with the attribute “drama”) should be implemented with memberships. That means the object doesn’t have the property “drama”, it is a member of the group “drama”. If the user and the object are members in the same group, the user has the specific permission to access this object. There can be different groups for showing, creating or deleting an object, like a simple viewer group or some kind of editor group. Furthermore there is a table that specifies which group types are relevant for certain actions on certain objects. For example relevant groups for the action “show” on the object "film" could be “genre” and “age” (film's suitability for certain audiences).
The reason to implement it in the described way is to have great flexibility without touching the code. Changes to groups can be processed in the database.
General database design:
Example: The film "The Revenant" is a member of the groups "genre:drama" and "age:18". The user can access it, if he is a member of these groups too.
Does this sound like a good approach? Are there any existing solutions that are similar to this approach? Does it have major drawbacks (e.g. too many database queries - there may be several hundred users every day)?
Please share your thoughts on this issue with me - the choice of "drama" as category for the example is not a coincidence ;) I just dont know if this is a dead end or if I am heading to the right direction. I stuck at this point for quite a while.
At least you have a good sense of humor :-)
Your approach sounds fine. So long as you keep the number of parameters low, then you can get away with role-based access control (RBAC) and a few additional parameters e.g. group membership.
But in the long run, if you want to implement business-driven authorization (access control), you need a way to do this independently of your code: you do not want to rewrite your app code every time there is a requirements change.
To do so, there is an access control model called Attribute-Based Access Control (ABAC) that will let you define your authorization policies independently of your code.
In ABAC, you have the following concepts:
an architecture which defines a policy enforcement point (PEP) and a policy decision point (PDP). The PEP sits in front of (or within) your app. It intercepts the business requests (e.g. a request to view a film) and sends an authorization request to the PDP. The PDP is configured with policies. Based on the request the PDP will reach a decision: either yes, Permit or no, Deny.
a policy language: the policy language is attribute-based (hence the name ABAC). This means that you can use any number of attributes (e.g. user role, user id, user group memberships, but also user age, user location, user subscription as well as resource attributes such as movie rating, movie category, movie price...)
a request / response scheme: this is how you ask for authorization. It is essentially a yes/no flow. "Can a user do X?", "Yes they can."
There are several implementations of ABAC out there - some of which are framework-specific e.g. CanCanCan. XACML and ALFA are two approaches that are not tied to any particular framework. You can choose from open-source and commercial implementations of either language e.g.:
Open Source: SunXACML, ATT XACML
Commercial: Axiomatics Policy Server
Related
I have a Workshop module that addresses different user groups. Hence I would like to surface different pages to different groups by default. Indeed I see an option to control the default page selection based on a variable.
My first thought was to split my users into different Multipass groups and then have a function that queries a given user's Multipass attributes for membership in certain groups. However, I don't seem to be able to check for group membership in this way, probably for security reasons.
What would be the recommended way to go about this?
The Foundry security primitives for resource visibility (as opposed to data visibility) are largely aligned at the resource level rather than within a given resource. (The one exception I know of that's relevant is within the Object View configuration, where you can set visibility on different Tabs).
An approach also depends on if the resource visibility is a matter of permissions (i.e. should a user outside a given group not see a given page - again separate from the permission to see any data within that page) or one of convenience (i.e. all users can see all the data and all the interfaces, but each given group should simply start in a separate place.
In the former case, (i.e. security) I think it'd be best to make a separate Workshop app for each team and then maybe wrap them all into a Carbon workspace. The resource visibility, configured as the actual resource permissions in Compass, should determine if it appears in the Carbon workspace for the user.
If it's just for convenience, you could build all the pages in a single Workshop app, then make a separate Carbon workspace for each team and set a parameter to determine the default page, as you mentioned.
so I just wanted to know if putting data in a dataset of an element is considered a security flaw even though it is meant to be seen.
For example, if instagram put the id of each post from their database into the dataset attribute in each post element
Another example would be:
Putting the id of the post in a dataset
OWASP calls this Insecure Direct Object Reference (IDOR) -- when you expose a "direct reference" (database ID, etc.) to an internal object to the client -- and it absolutely can be a security issue.
To quote OWASP here, which is a much better expert on this than any one person:
IDOR do not bring a direct security issue because, by itself, it reveals only the format/pattern used for the object identifier. IDOR brings, depending on the format/pattern in place, a capacity for the attacker to mount an enumeration attack in order to try to probe access to the associated objects.
So in essence, if you surface database IDs and thus the pattern they change in, and you have some sort of access control issue (you're relying on security by obscurity, or you have some sort of bug in your access control), an attacker can find their way to any object on your system because they know the ID scheme all objects follow and thus can enumerate to any object in your database.
This is a major flaw, but it's by no means the only one. Check out the OWASP cheat sheet on this for more details!
I need to build a PowerApp which presents a daily list of tasks to a user such as number of surveys to complete; within which postcode area etc.
They then want to complete a questionnaire; and store submissions in the PowerApps own Dataverse.
My thoughts are;
Ideally i would want to hook up Microsoft Forms (standard not Pro) so the PowerApp could either link to the form and pre-populate a unique ID or similar? they complete the form; and a Logic App would process into the DataVerse by unique ID. However not sure this is possible?
Other option is i design the Canvas App to complete the survey (similar to the Employee Engagement survey template) - but likely will have 30/40 questions - this would obviously have a direct link to the Dataverse so no Logic App required
Other options?
Thanks in advance
Rich
Stay away from Microsoft Forms for a 30-40 question survey. The conditional logic, error handling, input validation, etc are not robust enough. You'd likely get too much free text to produce any meaningful reports from.
Caveat being: Do external users (outside your Active Directory) need to access the survey?
If so, then Forms is likely the only way to go (unless you want to somehow manage PowerApps licenses for external users).
PowerApps will suffice.
I've read RFC7644, and RFC7643, and have a few questions.
First: how do I provision entitlements? I see there's a default methodology for provisioning groups and users. That includes a pretty straightforward mechanism for provisioning users' membership in groups, entitlements they have, and roles they have.
I also see that there's a mechanism for creating a group with members in it during provisioning.
What I don't see is a built-in mechanism for creating a group, and linking entitlements to it (or creating entitlements that are then linked to groups).
Do I need to build a custom schema extension for groups? Do I need to build a custom schema for entitlements?
My second question is: how exactly DO I create custom extensions and schemas? The RFCs are pretty vague about how you might do that while being compliant with their standard.
After re-reading the SCIM standard, I have an answer to at least the first part of my question.
"Group" resources are meant to enable expression of common
group-based or role-based access control models, although no explicit
authorization model is defined. It is intended that the semantics of
group membership, and any behavior or authorization granted as a
result of membership, are defined by the service provider; these are
considered out of scope for this specification.
What this means is that entitlements granted via membership in a group are out of scope for SCIM. If you want to provision entitlements (or non-Group roles), you need to implement it yourself, or build a custom schema extension/custom schema.
Unfortunately, the RFC has yet to yield how you would actually do that last bit.
I have a question about fiware-skuld.
Is It working Skuld within a federation?
Must be use globally or in each FIWARE Lab region?
It is not a good idea to run individually Skuld on each region. There are some
serious problems:
the users are global. The change of the user type (from Trial Users to Basic Users type) can be invoked only one time. The same is true for the notifications. Users do not want a
notification for each region.
there is a problem of synchronisation if each region delete their
resources when they want. Users must be notified only one time and
with a defined anticipation.
At this moment the scripts are invoked only for a region, but to support a
federation it is sufficient to modify only the scripts that delete resources to
iterate with each region.