Every page in our application can be accessed by any user not requiring any kind of
authentication. And this lesson will see how to ensure only authenticated users will
be able to have access to our application. You recall that every time we created a
new web screen we have been ticking the anonymous role and this is the first thing
that you need to understand. The role here uses these elements they are the basic
element that allows you to design your security policies in your applications.
They can be associated with these base elements, for instance these roles are associated with these web
screens and they are also granted to users. So there are basically two types of
roles. You will have them here. This gray role refers to our system roles they are
predefined in these base modules. And they are anonymous which means any user can
have access to that element. And the other one is the registered role which means
that only authenticated users, users that provide their username and password that are
authenticated in the application will have access to those elements.
There is also a third element here created by default. It is a user defined role.
A default role created for our customer support application.
So this is a CustomerSsupport user role.
What I would like to do now is go back to our screens and remove the anonymous roles so
let's see what happens if these pages can't be accessed by someone that is not
authenticated. Let's take the anonymous roles from these screens,
this one and the last one. Okay. Let's publish and see what happens.
You see here that when we try to access our application we are redirected to the log in
page. This log-in page is also on our eSpace and was created by default by service
studio and it's this one and basically what happens is these roles that are mapped in
this screen are validated every time you try to access the web screen or you try to
access the web page. If the user doesn't have one of these roles then there is a security
exception that is thrown that redirects the user back to the log-in page.
And if I enter here that the default password for the user for admin is admin .
So if I enter with this user, now I'm logged with the administrator, I again have access to all my pages,
to my application. What we want to do now is to create a user that has access to the
customer support application. Let's create a new user and do that we will need to go
to another application which is the users application which is installed with the
platform and allows performing end-user management and assigning roles to our users.
So let's go to the users application I will use here so this element on the header,
you will see I have here the users application. Let's go to the user's application this
user, the administrator obviously has privileges to use this application and to create
users and grant roles on this application. Go ahead and create a new user this will
be John Opps. And the user name will be John and the password will be 12345.
Let's repeat here and let's save okay we won't grant any roles yet to our user let's
just have our user to test to see if he can access the application.
I will log out and let me go back here to service studio to open the application and browser.
Now I need to log in and this time I am going to use John's credentials
12345 log-in and there you have it now John has access to the application.
Now we change our policy from having a totally open application that every user can
have access to it and we have an application where you need to authenticate .
You need to say who you are and register to have access to the application.
Let's go back to service studio , and change this a little bit.
Now we want to go to our main flow and remove the registered role so you saw that
when I created the user for John. When he logged in he had the access to these
pages because this registered role is automatically assigned to all users that pass
the authentication process that have a valid username and password.
That is why John could enter these pages, this validation here for the role was
successful. Now we are going to remove this registered role from here,
this means that only users that have the customer support users role will be able
to access the application. Let's see what happens to John when this happens when he
doesn't have permission. Let's remove the registered role and also this one and let's
publish again the application. I am still logged in as John and as you can see here, I am
not seeing the dashboard I am seeing invalid permissions page.
John doesn't have the customer support role so he cannot see this page.
There is a security exception that redirects this user to another page to an invalid
permissions page that is also present in the common flow. So you can customize this
page here as well. Even if I, let me show you one other thing,
even if I go directly to the unclassified issues page
or to the high priority issues page or even if I try to go directly to all of
these pages I don't have access to it and I always go to the invalid permissions.
What we want to do now is grant John with the role and he can see all these pages.
Let's log out again, let's go back to the users application and the URL is users
here and let's log in as the administrator again admin/admin let's find John.
Here it is, and let's grant John the role of our customer support user.
Here customer support user this one, let's add. Now John has this role.
Let's go back to the application and log out from here let me open again the
application and let's login again as John and you will see now that he has the
role he will be able to have access again to the pages. Even having a bookmark for
the unclassified or the high priority, he can now see all the information
on the application again. And that's it.