Security and Session Handling
This lesson is part of the Developing OutSystems Web Applications course.

Hello and welcome to the lesson on implementing security in the OutSystems
platform. Now security is actually a very broad and complex field and we're going
to focus on one specific thing. But just so you have an idea,
the OutSystems platform already supports things like HTTPS and integrated
authentication to your screens or web services, it has mechanics to prevent
code injection into your code and SQL statements, it allows you to select which
applications are deployed on which individual machines on your factory and,
as we will see in a different lesson,
it also allows you to implement exception handling where you can trap
certain errors including security. One thing that it can't do automatically for
you however, is decide what level of access each user has to the several areas of
your application. So when you're designing access control you need to be
able to decide who can do what: access screens, trigger actions, etc in your
applications. This needs to be obviously done and implemented by yourself. Now
there's two sides to controlling access. One of them is authentication and the
other one is authorization. Authentication is the process of
identifying who is trying to access your application and you need to do so by
validating the credentials of the user. Once the user is authenticated, you can
then grant him access, authorize him, to do certain things. So at discrete points
you need to validate if the authenticated user is authorized to
carry out that action. The standard way to provision users in the OutSystems
platform is through the built-in Users application. At its most simple you
create a user and you specify his username, password and name. Once the user is known
in your system you can then start to authorize certain functionalities. It's very
likely that you'll find that several users have the same
level of access so therefore the OutSystems platform also provides the
concept of groups. A group simply allows you to authorize a set of users with the
same level of access. You now know how you can create users and groups to
authenticate them. Once they exist in the system
the act of authorizing is done via the application roles. Now, every single user
in an OutSystems application always has the Anonymous role and as soon as he
or she logs in he is granted the Registered system role. Though useful, the
registered role is however too broad.
It is important for you to be able to specify at application-level certain
roles so that you can enable certain behaviors. You do so by creating them
inside the Logic tab of your module. Each role has its own Check,
Grant and Revoke actions and these actions exist as well in the registered
role. Once roles exist in your module and it's published, these become available in
the Users application so you're able to statically and via back-office
authorize users to do certain things, to have certain roles. In your code these
roles can be checked in the screens and actions. The simplest way to enforce a
certain role in a screen is using the properties of the screen as you can see
in the screenshot. In this particular example, if an anonymous user tries to
navigate to MyScreen he will be pushed to the login screen because a security
exception will have been thrown. You won't need to write any other code other
than ticking these role checkboxes. Now in the code you will want to use the Check
role function for the role that you want to validate. Common places that you
want to do so are: in an if widget, and therefore you can have two sections of
the screen that will appear to someone that has the role or not, and in your
code using an if statement
where you can decide if execution should take one path or the
other depending on the user having the role or not. So a very quick recap: you
have two built-in roles, Anonymous (that everyone has) and Registered, that
everyone that is logged in has. Then you can create custom roles inside of your
modules - and just so you know, these roles can actually be made public so they can
be used and checked on a different module. While you can authorize users
using the Users application it's also possible to authorize a user in
runtime using the Grant roll action or remove the role using a Revoke role. In
runtime as well, you can enforce that the user has a certain role by using the
roles properties in the screen or programmatically by calling the check
role for your role. As a closing note, it's important to mention that when you
create a custom role you can decide if it is to be persistent or not. If you set
its "Is Persistent" property to yes, it means that the role is stored in the
database and will be persisted across multiple sessions and this is the
default value. And that's it for implementing security in the OutSystems
platform. See ya.