How to implement server session validation scenario in MobileFirst 8?

Question

I have a problem with the following scenario using MobileFirst HTTP javascript adapters:

let's say the adapters call 2 methods,

login, that calls a back end service which authenticates the user and also returns a customer_id (input: a username and a password).
retrieveData (protected by security-check) that retrieves sensitive data about a customer by calling a back end service (input: customer_id).

How can we make sure that some client that has credentials to authenticate and have access to retrieveData, will request only data that concern him and not be able to send a request sto retrieveData with a different customer_id from his own? (We assume that this client has tempered with the app and has made it send different customer_id's.)

With MobileFirst 7, after login was successful, we would call setActiveUser setting the returned customer_id as an atttribute of active user or we would call WL.Server.getClientRequest().getSession().setAttribute and again set the customer_id. So when a user called retrieveData, we would take his customer_id input and compare it to the customer_id in his session. If it was different, then they would get an error because they requested data that do not belong to them.

Since MobileFirst 8 does not have a session, how can we prevent this scenario from happening?

What is the relationship between a username and a customer id? And how is this relationship stored? — Nathan H
a customer logs in using a username and a password and login back end procedure returns a unique customerId (it is one for each customer, created in registration and never changes). This customerId never reaches the client app for security reasons. — papakias
You mean they get a different customer id every time they login? Or do you store this is in some persistent storage such as a database? I mean, your "retrieveData" uses the customer id as its input, how does it know which data to retrieve with this id? — Nathan H
No as I said in my comment above the customerId never changes. It is created once during registration of a customer and it is stored in a database. (the login back end service retrieves it from the database after in validates the customer's credentials). So every customer has a customerId. That's how the retrieveData knows whose customer data is going to return. — papakias
So in retrieveData can't you check that the customerid matches the username in your database? — Nathan H

Nathan H Nathan H · Accepted Answer · 2016-08-25T08:42:14

In 8.0, "Client Registration Data" is the closest thing to a session.

There are a lot of unknowns about your use case, but I will try to describe the expected behavior is most cases:

Assuming your security check extends UserAuthenticationSecurityCheck, as soon as the user succeeds to login, his user id will be registered in the client registration data on the server. This will map the client to the user in a database.

From that point on, on any adapter you can safely check who is the currently logged-in user by using securityContext.getAuthenticatedUser().

If you want to make sure that a client only accesses data it is allowed to, use this getAuthenticatedUser to check against your database that the requested data belongs to it.

If you really need to store extra custom data in the registration context (the closest thing to a session object) there are APIs in the security check to do so. See RegistrationContext.

How to implement server session validation scenario in MobileFirst 8?

2 Answers