GeneXus Access Manager (GAM) solves authentication and authorization issues for GeneXus applications (web applications or Native Mobile applications).
The purpose of this document is to briefly explain the main concepts around session management used by this kind of application.
There are two types of "sessions" used for solving security mechanisms, depending on the type of application (referring to applications using GAM):
In Web applications, "web sessions" are used to store all the information needed to solve authentication problems (remain authenticated as long as the session does not expire).
Web Session timeout has to be configured for each GAM Security Policy using the WebSessionTimeOut property of GAMSecurityPolicy external object.
See the following code as an example, where the security policy is loaded, and its session timeout is changed:
&SecurityPolicy.Load(&Id) //&Id belongs to GAMKeyNumLong domain
&SecurityPolicy.WebSessionTimeOut = &WebSessionTimeOut //&SecurityPolicy is GAMSecurityPolicy data type. &WebSessionTimeOut is N(4).
Using the Web Backoffice you can configure the session timeout by executing the GAMExampleEntrySecurityPolicy Web Panel (which is part of the GAM - Examples):
The Web Session Timeout configured in the Security Policy has to be less than or equal to the Session Timeout configured in the Web Server.
In Native Mobile applications, there is a "local session" stored in the device (the client tier) with the access_token that enables communication with REST Web Services which require authentication (see Secure Native Mobile applications architecture for more information).
Unlike web applications, where authentication is checked via web sessions only, native mobile applications cache a "local session" that stores the access_token which makes communication possible between the application installed on the device and the REST web services residing on the server. In this case, the authorization mechanism is based on OAuth.
In order to connect to a secure Native Mobile application, the end user will need an authorized username/password. These credentials will be used together with the Client Id and Client Secret information downloaded to the device when the application is installed, in order to establish the first connection to the server application.
When the user tries to connect to the application, a login is displayed. The first time he tries to connect, a POST is made to the server using username, password, client_id, and client_secret, and the HTTP Response returns an access_token which will be used for the length of the connection.
This access_token is stored in the device and can either remain unchanged while the user is connected or be reset regularly depending on the value of the Token expire (minutes) property (available as an option of the Security Policy, see Figure 2).
The access_token is stored in the device cache, and while it's valid (the user does not log out) the end user will not be prompted with the login again.
The local session is eliminated when the user logs out from the application.
1. The time expiration criteria for "OAuth Token Expire" is different from the web session expiration timeout. The latter involves idle time, and the former is related to elapsed time.
2. Remember that all the Security Policies and Repository configuration can be done through the GAM API.
Ex: The following code creates a Security Policy and sets SessionTimeout and OAuth Token Expire.
&SecurityPolicy.Id = &Id //&SecurityPolicy is GAMSecurityPolicy Type
&SecurityPolicy.Name = "TESTSecurityPolicy"
&SecurityPolicy.WebSessionTimeOut = 10
&SecurityPolicy.OauthTokenExpire = 15
&Errors = &SecurityPolicy.GetErrors() //&Errors is GAMError collection type
For &Error in &Errors
Msg(Format("%1 (GAM%2)", &Error.Message, &Error.Code))
Secure Native Mobile applications architecture
Anonymous Sessions in GAM - Web Applications