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.
Related
I use ansible to manage a wide range of VMs, all with their own specifics, but each have some roles commonly defined under them.
Eg. multiple playbooks reference a role, that sets up admin users with access, same goes for ssh setup, timesync, timezone etc.
Now these roles are explicitly referenced in the same way in these playbooks, which is hard to maintain if a role happens to change.
I tried two methods:
Include playbooks: While an included playbook can be ran for an inventory file, which would cover all the needed VMs, it still has a separate configuration set, and I would try to avoid possible misconfigurations with included playbooks
Master role with included roles: I managed to make this method work by passing variables, however it is a bit hard to set up, not to mention because of this maintainability and tracability of variable flow defeats the purpose of ease of use.
If anyone more experienced, is there a suggested way to group commonly used roles together while still having the option to use the separately if needed?
I would not want to say that I'm more experienced, but I do have a way of 'making it work for me', and am also struggling with the question if this is the best (or at least a good) way of doing it.
My hosts are divided in groups, and each group has it own set of
variables in group_vars.
I have a single playbook for each top-level
group ("server" and "client").
The roles are split up according to
function ("webserver" or "gnome-desktop").
Whenever a role is used by multiple hosts or groups, I use conditionals based on
inventory_hostname, groups or a custom variable. This does generate
some repetition, but that can be kept minimal by conditionally
importing tasks.
To be completely honest: I'm not there yet, but in a few weekends from now I hope to get there :-).
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
I want to provide a user the ability to cache up to 2,600+ items, by groupings (categories of book, individual books, or possibly even just chapters of a certain book if they don't want the whole book). It is not possible, as far as I can tell, to precache all of these items because there are 2,600+ of them, and will be more in the future - the service worker will timeout with under a couple hundred. And since service workers either get all or none on install (if I understand correctly), do I need to use multiple services workers (with different ids?), or am I thinking about this wrong?
What I am thinking is something like...
<iron ajax></iron-ajax>
<template is="dom-repeat" items="...">
<platinum-sw-register auto-register clients-claim skip-waiting>
<platinum-sw-cache default-cache-strategy="fastest"
cache-config-file="../someGenerator.php"></platinum-sw-cache>
</platinum-sw-register>
In other words:
Get a list of wanted URLs via iron-ajax (based upon what the user enables for cache)
Iterate through the URLs as groups via dom-repeat
Create a service worker with a customized cache-config for the URL group
Repeat 2 and 3 until done, then present a toast
That someGenerator.php would return a JSON config setup for the particular group of URLs.
My app is a single page app - with neon-animated-pages - one page representing categories, one for book listings, one for table of contents for each book, and then one of each the chapter contents. All of the data is obtained via iron-ajax.
Here are some links to demonstrate the issues:
The App
A large non-functional cache-config generated
I suspect, in order to not have service workers errors due to redundancy, or overwrite existing caches, I will need to assign individual ids, and include them in the generated cache-configs. Does that sound right?
No, I don't think that's the right approach. <dom-repeat> and creating multiple service workers isn't going to accomplish what you want.
It does look like you're bumping into some service worker-imposed timeouts during your install handler due to the delays in fetching the JSON configuration and performing all of the precaching. Taking a step back, are you sure that you need that entire set of URLs precached?
<platinum-sw> will give you runtime caching as well, so that when a browser loads a given URL when there's a network connection available, the resources will be automatically added to the cache and available offline during subsequent return visits.
There are other approaches that would use either window.caches to cache resources from within your controlled page, or using something like postMessage() to communicate a list of additional URLs to cache from your controlled page to your service worker. Both of those approaches would involve going beyond the default functionality you get from using <platinum-sw> and digging into the internals a 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.
How many ways are there to learn implementing workflow of a software? What are them?
If you mean the user workflow, how the user is guided through the software...
I usually use some sort of state machine to limit what functionality can be triggered by the user and what information will be presented to the user in a particular state of the workflow. This way I can concentrate on designing each segment of the flow in its own "sandbox" and decision making becomes a lot easier.
If you do not mean user workflow, you can ignore this reply.
Usually you do have steps in workflow. Step consist of some precondition (business logic hidden from UI), some user interaction (user entering some data, and doing some “user stuff”), and post conditions. Usually user interaction part has one or more user chosen “exists”, and every exit consist it’s own post condition (usually every user exit has it’s own business logic depending of a meaning of an exit from a step). Exits navigate workflow to next step. Sometimes you can have fully automatic steps (i.e. using some external data source, calling some web service, important calculation, and so on).
If your workflow is simple, you may implement it as a set of classes representing each step, and configuration of steps order can be put in XML. When your workflow will grow bigger, and bigger, it may be reasonable to search for some workflow engine, (discussion of WF engines is I think beyond the scope of this question).
One important thing – steps can be orthogonal, but it is harder to design. If your steps rely one on another, person configuring workflow and steps order must be fully aware of such dependencies (e.g: user address step will probably depends on user object creation step, and removing user object creation step from a workflow, will result in trying to access nonexistent object).