Home will denote the scenario of a house in a town called Springfield where Bart lives with Homer as the administrator. Most of the use cases that might be encountered in everyday life have been gathered, as you can see in the picture.
The house is one of the greediest users of media you can find.
There are a desktop or laptop, computers, tablets, smartphones, gaming consoles, and connected TV, and our house project must use all of them at the same time. Nevertheless, you don't want to worry and spend your time on which user is connected to the tablet and what they are doing. While you have to manage these accesses, you'd certainly prefer to focus on the TV show and eventually take 5 minutes to allow the publication of some posts. You know how easy it is now.
As shown in the preceding image, we can list some of the activities for the Springfield house's users. They want to:
- Watch movies
- Listen to music
- Have some podcasting
- Access online resources such as VOD/YouTube
- Install a Wi-Fi camera at the entrance
Now, we need to list all the users to give them the corresponding rights. This list defines the functionalities that can be accessed by each user:
- Bedroom 1 user: Bart
- Bedroom 2 user: Lisa
- Bedroom 3 user: Maggie
- Kitchen user: Marge
- Main room user: Homer who will manage the house (yes, he believes that he can manage it)
- Unknown: This part is left as a joker for those who "Bring their Own Device." This is a category for some eventual visitors, which needs to be defined in our scenario as well.
Now that you know the users and what they can do in the house, the security perimeter is defined. What is left to know are the access types that can be granted to these users. This list is a tool to understand the consequences for each role you assign:
- Authenticated users: These users just need to view and upload media. They only need (or want) to be granted minimum access.
- Guests / people passing by / friends: This is to allow your friends or some guests to access a part of your media without needing to log in. By setting this kind of access, you ensure privacy for yourself, as the embedded player will only be visible if the user is logged in. In this way, we make sure that if a visitor comes, he will not be shocked by Homer's contents.
Note
As each user has already been identified by a login to your local network, you already know that this user is granted access. This implies that anonymous users who might eventually try to connect can't access and obtain MediaDrop guest rights; therefore, they won't have access to any content, meaning they cannot post or read without your network's consent.
- Power users: These users can't do everything they want, as they inherit authenticated users' rights plus an additional ability to grant access to someone else. This role can be granted to anyone that you can rely on when you are unavailable for some administrator tasks. For the sake of the example, let's say this will be Lisa.
- Administrator: This is someone who is able to access the admin panel we have seen earlier in Chapter 2, Media Management, Shares, and Social Activities. If you want to keep your security strategy as stable as possible, there should be very few administrators: imagine everyone changing the access roles and granting access to guests, leading to a security breach.
We now have all the prerequisites in place, so we can create our users in the house. What we are doing now is using the predefined groups of activities and setting users within these groups. Additionally, we are also creating our own group to see how easy it is.
To get started, connect to the admin console and select Groups on the interface so that you can see what rights are provided:
You can now associate the users with the predefined list of roles you want to grant them:
Let's take a look at this table more closely:
- Anonymous people can view media, but we don't want them to upload new content, and most of all, they shouldn't be able to grant anything.
- Logged-in users, on the contrary, don't have enough privileges; they should at least be able to view and submit content
- Editors and Admins do their job correctly, so leave those as defined
We can see here that this doesn't fit our philosophy, so let's change the group settings to those used for our house. Let's bring in a few modifications:
|
Can view published media |
Can upload new media |
Grants the ability to upload new media |
Grants access to edit site content |
Grants access to the admin panel | |
|---|---|---|---|---|---|
|
Everyone (including guests) | |||||
|
Logged-in users | |||||
|
Editors | |||||
|
Admins |
What we did is we assigned different roles to different people. Editors will be able to set upload and edit accesses, while Admins are allowed to play all the roles.
Most of the time, you won't need all these roles, so here we just stick to Everyone, logged-in users, or Admin. However, it is recommended that you set up all the roles for future use, as you might need to delegate Editors for extra emergent cases or even as a temporary role that can be removed later.
The job is nearly done; only modifications are left to be set, which will only take a few minutes.
To define rights according to our house's strategy, we just have to modify the existing rights:
- Everyone: Click on the Edit button for this group, set only View Published media as checked, and click on Save
- Apply the related modifications for Logged-in users as well
What you need to do now is define your users; don't be surprised if just the Admins and Editors groups are proposed, as the Logged-in users and Anonymous are implicitly identifiable.
This should end as shown in the following screenshot:
We come to the end of the home scenario, resulting from our previous analysis and lists of users, actions, and roles.