BeagleBone Media Center (2015)

Chapter 3. Examples of Real-world Situations

In the previous chapter, we looked at how we can use MediaDrop to publish our content. Now, we are going to discuss security, which is another important aspect of everyday life. You don't just ask the BeagleBone server to provide your content, but you also ask it to share this content the way you want. Here, you will see how security roles can ease administration tasks and how MediaDrop provides such a mechanism in the administrator console. To be as practical as possible, we will go through two scenarios and analyze them in a concrete manner: home and professional. The home scenario will be a good representation of the use cases that are encountered in everyday life, whereas the professional scenario will deal with use cases from a company where employees need to share media and access e-learning videos.

In this chapter, we will cover the following topics:

· Introducing the security role

· An everyday use case—a house in Springfield

· Second use case—media management in a company

Introducing the security role

As we live in an interconnected world, we are exposed to misuses and attacks. As we will see in this chapter, security is of utmost importance irrespective of whether it's a small or large network. Even if role definitions require additional work, you should take the security of your network into consideration. Just like you fasten the seat belt in your car, you'd rather spend this extra time once and forget about it thereafter.

It can be summarized in 3 processes: write down all users who will require access, itemize what resources they will have access to, and then connect the dots between the lists. That's what we are going to see now.

An everyday use case – a house in Springfield

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

Defining your users list

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.

Understanding role attributions

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.

Group management

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.

Note

Even though this is not about the protection of jewels, you don't want anyone to be able to set rights. This is obviously a security breach: anyone can grant other people the right to upload.

· 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:

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.

Applying groups and users

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.

Note

Most of the e-mails are real ones from the episodes; you can check this.

Second use case – media management in a company

As we already saw how to organize roles in the previous topic, this part will focus more on the professional approach. With a very small budget compared to those that many IT departments require, we are nevertheless going to see how this solution can fit into professional contexts.

By taking a look at the following image and comparing it with the home scenario, we can see that the use cases for a company are organized into a different architecture in order to connect users. In addition, we can easily guess that the repartition of roles will be totally different because of the clear differences between departments.

The company's network is now structured as "grapes" with dedicated subnetworks for each department's activities. As the IT manager, you have to define roles:

· The welcome presentation: This is a movie player for customers

· Guests: This gives your visitors and customers access to some of your content

· R&D department: This needs to listen to music, access company streaming contents (for example, e-learning), and podcasts

· Media department: This provides contents and podcasts

· Marketing department: This has access to movies (presentations) and podcasts

· IT department: In a word, you are responsible for administration, but this role can be split into many people

Managing policies and groups

If you remember the table from the previous home scenario in the same Group management section, you might remember that we had quite the same repartition between users' types and their roles. Some differences remain, as we split more roles within our users; so, Editors will manage the site's contents only, while the Uploader Admin will manage upload attributions except the Editions ones.

Therefore, with these exclusive roles, rights management is guaranteed, as only Admins will be able to get all the roles.

So, we will set some roles, as shown here:

What we can see in the preceding screenshot is that a part of the administrative tasks can be shared with trusted people. So now take as an example the IT department being made up of the following roles:

· Admin

· Editor_master

· Upload_master

These roles also share some group attributions with the following:

· User1_RnD: Editors

· Mediadept_user1: Upload Admins

These have some delegating ability but not complete admin rights.

What about users such as John Doe from the marketing department and the presentation player in the hall? Actually, as they don't provide content, they don't need special user access; therefore, they just need to be authenticated logged-in users.

Self-test questions

Q1. Where do you get users groups' settings?

1. In the Setting menu

2. In the groups menu

3. In the users Menu

Q2. True or false: In order to access a user's settings, you need to be logged in as an admin before accessing it.

Q3. If you want the user Bart to watch and listen to the house's contents, you will set his role as:

1. Authenticated user

2. Anonymous

3. Administrator

Q4. True or false: Security requires enough additional time. Having an extra 10 minutes to obtain these details and write down lists is not useful. After all, your network already has some credentials

Summary

We have been through a dense chapter. You might not be a security-passionate person, but it is most likely that you can now understand why you should consider this topic, and maybe your point of view might have changed. Hopefully you'll take a few minutes to define your security strategy based on the examples in this chapter.

Remember to find answers to the who, what, and how questions through the lists you have defined at the start so that you just need to set or use predefined roles in the Groups and user interfaces.

Using real-world and practical examples, we saw how the Springfield house is organized to let everyone be happy with media, in the bedroom or even in the garden.

We also saw how security can be applied to professional aspects as well, with the hope this part will help you the next time you need to apply a security strategy and architecture.

We will now leave the MediaDrop world to let you provide the content and become an actor yourself and share movies.

In the next chapter, we will be more creative, as we will set up our own content as well as services.