Purpose
As part of the ODTUG KSCOPE14 conference, I gave a talk: Cookie Monster - Understanding how and when to use browser cookies with APEX. In that talk I described the technical features of cookies and how the APEX framework uses them.
As the talk progressed, I used the example of how Amazon always seems to know who you are, and how APEX will always throw you out if you close your browser. Even though Amazon knows who you are, any time you try to touch something sensitive such as account details or transactions, Amazon will challenge for authentication credentials. I continued by showing a method in which you could use the Amazon style authentication for APEX applications. It requires a little setup, but it is very possible to do within a single application.
The example application included here operates with APEX in the same way. You can authenticate once and choose to save a “Remember Me” cookie. This cookie will allow you to come back to the application and it will remember who was last authenticated (although not the same sesison). Using an additional check, we can determine if the user has actively authenticated for the current session, and if not, require them to re-confirm their credentials.
** UPDATED ** Download Presentation and APEX Application V1.1 (4.2.2 required)
Demonstration Application on APEX.oracle.com
The High Level Idea
There are three authentication states.
- Authenticated Automatic by Cookie
- Authenticated This Session
- Not Authenticated
An active authentication (user enters password) will set an application attribute that can be used to identify the current APEX session as authenticated. If the user on login chooses the “Remember Me” option, a cookie is set on their browser that allows them to automatically Authenticate next time they come to the application. The application attribute is used to differentiate the difference between authentication by cookie and authentication by password.
The next time the user comes to the application and needs to provide authentication, the application will use the “Remember Me” cookie to authenticate the user. APEX will see this as an authenticated user, but the attribute will show it as an “Automatic” authentication.
Automatic Authentications identify the user to APEX, so as far as APEX is concerned, the user has authenticated.
For sensitive pages, we want to re-challenge anyone using the application with automatic credentials. An authorization (Auth-Z) scheme has been configured to enforce this requirement. When a SECURE page is requested, and the user authenticated with the “Automatic” cookie, they will be re-routed to the login screen. This can either be done with a branch, or with an authorization error notification. (Other designs are also possible)
Steps to Reproduce
Public Home Page
The home page on the application (Mobile or Desktop) is public. It will show either additional pages or tabs when a user is authenticated.
Standard Login
This demonstration has been setup with a dummy Authentication (Auth-N).
- Click on either LOGIN or on the “Go To Page..” button.
- Enter TEST for user name
- Enter TEST for password
- Check the REMEMBER ME check box (if not defaulted) to generate a Cookie.
- Click Login
- Navigate back to the HOME page, you should see additional tabs or pages (Mobile).
Clear the Session
Starting a new session will effectively log you out of APEX. This is the same effect as closing the browser and coming back to the application. (some browsers will remember session state, so your mileage may vary)
- Click the “Start a New Session” button.
- The tabs or pages should be removed.
Auto Authentication
This will show the cookie authentication working
- On the home page, click the “Go To Page..”
Normally, this page would default to the Login Page. With the “Remember Me” option, it will automatically authenticate the user and navigate to the destination page. The footer of the page should identify the user as having used the cookie authentication.
Navigate to a secure page
Navigating to a secure page will identify the session as automatic - and either generate an authorization failure (Auth Z) or generate an automatic branch back to the login screen.
- Click the Secure - Auth-Z Tab
- Click Back
- Click the Secure - Branch Tab
- Login as before
- Secure page is shown
Deep Link Feature
A good authentication feature should automatically navigate the user to the page requested. The login page here has a feature defined that will set the post login page when needed.
Logout Feature
The feature built into the logout request (same page as login) will clear the “Remember Me” cookie as well as the current session.
- Click the Logout Button
- Click the “Go To Page..” button
- Notice Auto Authentication did not occur
Mobile
This example can also be run on a mobile device (same application - using auto detection)
Pseudo Code Description
Standard Login
(Page 101 / 1001 (Mobile) Called directly with no request)
- Authenticate User (Package Code)
- If Valid Authentication and Remember Me Requested - Write Cookie
Automatic Login
(Page 101 / 1001 (Mobile) called with request “AUTO”)
Cookie is read and validated against table store (Package Code)
-
If cookie is valid …
- User is set
- Application Item set to AUTO
- If Post Login Page is given - redirect
- If no Post Login Page is given - default apex behavior
-
If cookie is not valid …
- Default to login page with no request
- Application Item is set to NULL
Authorization Scheme (Auth-Z)
- Validate Application Item = PASSED indicating a valid session login
- Provide link in the message to default login page - No request in the link.
Secure Page Auth-Z
- Authorization is tested at the page level
Secure Page Branch
- A “before header” branch is configured to call the LOGIN URL (no request) and set the Post Login page to the current page.
- This branch uses the Auth-Z as the security scheme.
Logout
- Page 101 / 1001 (Mobile) called with request “LOGOUT”
- Package code that clears the cookie and logs out the session using standard apex features
Cookie
- The cookie is written as a HTTP only cookie
- The cookie key is in a custom table that was created on install
- The “user agent” is used with the key as an added level of security (this is just an example of how the cookie structure can be modified to your needs)
- There is an expiration date (30 days) for the cookie both in the browser and the table
Is it Secure?
That depends on who you are and what you are doing. Here are some considerations:
- Are you using HTTPS? - This will increase the security of cookies and cookie transmission.
- Are you displaying sensitive information if they cookie authentication is used?
- Are you working on an internal corporate network only?
- Do you review your code for security compliance?
Your Design
There is more than one way to address the protection of sensitive data. This example there is simply one of many suggestions. Applications which contain sensitive information should always be evaluated extensively to assure security and effective design.
Notations
My history on this topic goes back some time, but never in a way that was presentable to others. There were always too many specifics that made the application only applicable in my situation. This here is an attempt to take what I have done in the past and make it understandable by others, and maybe even useful.
Credit to those who have done similar work is implicit into all of my posts, if not explicit. In this case, Christian Rokitta did an excellent post on APEX and Remember Me options. His approach similar, and an great learning platform.