info-beamer

Multiuser Support


#1

Hello

First, I’d like to introduce myself quickly.
I work as an IT manager in a smaller production company in Switzerland.

I saw this software for the first time at a Chaos congress. As we are looking for an Infoscreen solution, I took a closer look at InfoBeamer…

And I like what I see.

But I wonder if there is the possibility to control the content from the info beamer, by several users, possible also with several rolls.

In our case, the IT department would manage the equipment and the HR department, as well as our reception would maintain the content.

I can also share the access data to the account. But I find it unsightly.

regards,

John


#2

+1 for this feature, would be very handy for our Company, instead of sharing the same login.


#3

Yes. This is being worked on. Here’s a sneak peek of what some of the UI currently looks like. It’s probably going to be clean up a bit before release:

The basic idea is that an account owner can invite other users to their account while setting permissions for the invited users. Once an invite is accepted, the invited user has the option to switch between accessible accounts. So they still have their own account, but can switch to other accounts they have been invited to.

ACLs will allow fine grained permissions on all entities and actions within an account.

You can also invite yourself to your account, to get additional API keys. This allows you to create limited keys that (for example) only allow the caller to access the account information API call to see how much credits you still have for something like an automated check.

No ETA yet, but specific user cases might be interesting to know.


#4

I have one wish regarding the invitation. So that I don’t have to list you in my collection of data processors (GDPR and stuff like that).

Would it be possible to create an invitation token with which someone can register themselves?
As soon as he has registered, I could unlock him for access. (in case someone guessed his token and tries to get access - recognizable by a mail address unknown to me)


#5

I’m not a lawyer, but how would that make a difference? The end result is the same: Both (inviting account and invitee) see each others email address once confirmed. I’m all for making the service as privacy respecting as possible, but I don’t fully see how your suggestion would help here. I probably don’t fully understand what you’re suggesting.

Right now the flow would be like this:

  • A and B have an info-beamer account
  • A enters B’s email address in ‘invite box’.
  • B sees the invite and either accepts or rejects it

At any point, A or B can revoke/cancel the access. How would you suggest this works?


#6

yes, that should work… i was probably with my mind at another service provider where you could only create accounts with an invitation.


#7

Ah. Ok. You’ll never need an invitation to use info-beamer.com :slight_smile:

I’ll keep this topic updated if there’s more to see/test.


split this topic #8

4 posts were split to a new topic: Subaccounts and floating licenses


#9

When this will be available ?


#10

When its done. There’s still no ETA.


#11

Work on the permission system is making big progress. Expect a first release soon. Here’s a few screenshots of the new UI and a few example uses.

Shared access page

You can now share access to your account with other users and other users can invite you into their account. Once such an invitation is accepted by you, you can switch between accessing your own account and the other account(s) using the new “Shared access” page. It’s accessible from the menu at the top right corner:

Clicking on Switch to access on another users account lets you access that account. Of course the user that invited you has full control over what you can actually do in their account.

Your own account is also listed here. If you want to switch back to your own account, just click on its Switch to access button. You might wonder why my account (fw@info-beamer.com) is listed multiple times. Check out self access below for more information on this feature.

New permissions tab

Managing access gets its own tab. You can control access to your own account, manage the accesses you have to other accounts and use or create your own rules on which permissions apply.

Access tab

The “Access to account” tab shows you who can access your account. The first line is an auto-generated access that allows you to access your own account. The second line allows otheruser@example.net access using the Test Access access control list. Finally the third line allows you access to your own account, but with limited permissions controlled by the Read-only account access access control list.

Accessible accounts tab

Next is the “Accessible accounts” tab. You can see all accounts you have access to. This is essentially the exact same list you saw in the Shared access page listed above. If you no longer need access to one of the listed accounts, you can leave it here:

ACL tab

The ACL tab allows you to create, edit or delete access control lists (ACLs). ACLs bundle up any number of policies. If you want to manage multiple users accessing your account and all of them should have the same permissions, a single ACL is enough for that. If you need different permissions for each user, create one ACL for each one of them using different policies.

When you click on any of the ACLs you can see which policies they use. You can add a policy to an ACL by dragging it to the “Assigned policies” column.

Policies tab

Policies are what actually controls if an actions is allows or denied. Policies can be used in any number of ACLs.

A policy is a (usually short) JSON document that lists an action, an optional condition and an effect. Every action made by another users to your account can be controlled that way. Example actions are device:create, setup:update:config or asset:update:filename. The API documentation will be updated of course to describe which API call corresponds to which action.

The effect is either deny or allow.

The condition value adds the real power to the policies. Here you can describe which condition must be matched before the policy has an effect. You can usually check for different attributes of objects (devices, packages, setups, assets, etc) that are created, modified or deleted.

For example you can ensure file renames are only possible in the test folder with the policy shown below. Conditions also allow you to limit certain action to a subset of everything in your account. So you can deny a user access to any device with a name starting with reception/*. Finally you can match for per-request values like the remote ip or current time. This can be used for example to make sure that some device cannot be edited unless the logged in user is currently using the dashboard from your office network. For some objects it’s also possible to match values set in their (usually hidden) userdata value.

To make things easy, there will be different useful policies available by default. Those might be “Device Administrator access” (full access to all devices), “Device View access” (read-only access to all devices). Instead of writing your own policies you can then just use them to build your ACLs.

Multiple API keys per account

Above you saw that you can have multiple different accesses to your own account. You might wonder why that’s useful: Each access does have its own API key and ACL. This allows you to create additional API keys for your own account with limited access. Here are several examples where that might be useful:

  • Some users use the account information API call in their monitoring systems to check if the account balance will reach 0 soon. Previously you had to use your single API key for that. This means that your monitoring system has complete access to your account, even if it’s only interested in how many credits you still have. With the new permission system you can create a new access to your own account, add a ACL with a single policy that only allows access to the account information call and use that API key for your monitoring system. Even is the API key leaks, it can’t be used for anything other than the configuration use case.

  • Integration into automated pipelines: Previously every package imported had a webhook URL. This URL could be used to essentially trigger a package update API call without authentication as a secret component was included in the called Url. This feature will be removed but can be fully replaced with the new permission system: If you want to allow an automated system to update some of your packages, you can now create a new policy that only allows the package:update:sync action for certain package_ids.

  • If you want to create a custom ACL used for sharing your account with another user, you can test this ACL yourself by creating a new access to your own account and assigning that ACL. You can then verify that the policy works as intended before assigning it to a real user.

Structuring account access

The permission system is really flexible. If you want to set up a signage network with multiple users, you can now create a single master account. This account has all the devices, setups, packages and assets. Your users then create their own account and the master account invites those users. Of course while assigning custom ACLs to each user. You can for example have an ACL that only allows users to edit devices with a certain location name.

When the users log in, they first end up in their own account, but can easily switch over to the signage network account and modify only their devices.

Next steps

Which this all looks fairly complete, there’s still some work left. A big part is documentation as this feature can be quite complex. So there’s still no final ETA for the feature, but it’s pretty close now. Feedback welcome.


#12

That all sounds fantastic :slight_smile:

Regarding assets, can you confirm that a sub-account will only have access to the assets relating to that account? or are you saying that will be user configurable?

As this would make it much easier to create setups and playlists when only working with the relevant files.


#13

This feature has actually nothing to do with sub accounts.

Instead it allows you to describe relationships between any account. So between your main/sub accounts, or the accounts of other users.

You can allow other users access to your account and assign limiting permissions for that access. One option of limiting access is for example to prevent a user that has access to your account from changing anything other than files in a single directory. Or for example only being able to edit a single setup.


#14

Currently writing the documentation. Sneak peek: Prevent device reboots during the middle of the day using this policy:

{
  "Action": "device:reboot",
  "Condition": {
    "TimeAfter(Europe/Berlin)": {
      "request:time": "06:00"
    },
    "TimeBefore(Europe/Berlin)": {
      "request:time": "22:00"
    }
  },
  "Effect": "deny"
}

or since that’s now best practice ( :wink: ), here’s how to prevent access to the API using curl:

{
  "Action": "*",
  "Condition": {
    "StringLikeIgnoreCase": {
      "request:user-agent": "*curl*"
    }
  },
  "Effect": "deny"
}

#15

This feature is now online. Right now it’s hidden behind a feature toggle on the account page as I feel that there’s not yet enough documentation available on how to best use the system. That’ll change once there’s more user feedback. Have fun giving out permissions and testing out the system. Also you don’t have to worry locking yourself out of your own account. That’s not possible.