Operations // Careers & People
6/5/2014
12:00 PM
Garret Grajek
Garret Grajek
Commentary
Connect Directly
LinkedIn
Google+
RSS
E-Mail
50%
50%

If HTML5 Is The Future, What Happens To Access Control?

The solution for multi-device deployment is HTML5. The challenge, for the enterprise, is deploying it correctly. Here are seven tools you will need.

The use of HTML5 versus other media-centric mechanisms for cross-device support is the latest tech topic causing passionate debate among IT aficionados. Most of us knew Flash would not prevail when Steve Jobs prophetically commented in April 2010, Perhaps Adobe should focus more on creating great HTML5 tools for the future, and less on criticizing Apple for leaving the past behind.”

We now have an explosion of HTML5 creation tools and some really creative ideas of what to do with them. This goes beyond games and videos to include full enterprise data and access control, like Sencha Space, which provides cross-device support and data, and application support agnostic to the device -- a true BYOD solution via HTML5.

With HTML5, the focus is back on apps and data rather than the device. What was the shift? The shift was away from proprietary platforms that limited cross-device support, and the solution created apps that were device specific and required device control for updates and management.

HTML5 promises a cross-device platform and the wonderful ability of server-side control of app logic and content. HTML5 even introduced concepts like HTML5 Semantics, where the coder expresses the intent of the action and the device handles the interpretation and specifics.

End of mobile device management
When done correctly, HTML5 frees the enterprise from mobile device management. Resources can be deployed to all devices in a manner that allows complete abstraction of the device to the app. The good news is that it places the focus on the apps, not the devices, an area that enterprises can manage more effectively.

Enterprises need to take these resources, which are, in the HMTL5 world, URL-addressable, and construct access policies that are aligned with corporate policies on two-factor authentication, SSO, time, geography, and device limitation.

Fortunately, these tools all exist. Enterprises do not need to do what they did in 2008 through 2010 and go purchase and deploy all new security and control mechanisms for the purpose of locking down the new devices.

The mechanisms for HTML5 app access control exist. It’s now up to the enterprise to place an inventory of what tools they have and augment them accordingly. Key components should include the following:

1. HTML5 development tools. There are several robust and proven technologies in this space to help an enterprise take advantage of the cross-device coding advantages of HTML5. Even Google has joined the crowd with the launch of Google’s Web Designer.

2. URL-based access control. This includes single sign-on (SSO) to directories, two-factor URL-based authentication, and SSO into multiple mobile, web, HTML5, and legacy applications. For SSO to directories, it is important to work with what is already in place. Use the existing directory information (AD, LDAP, SQL), and employing multiple directories should not be hindered. SSO to multiple applications makes the solution more complete and convenient to end-users. This enables transparent access to existing web applications, cloud resources, HTML5 applications, and non-HTML5 mobile applications.

3. Two-factor authentication/access control. The two-factor URL-based authentication is key for any solution; and it should be built right into the workflow for security and ease-of-use, be based on existing groups and policies, support multiple mechanisms, and be browser-friendly. Browser-friendly authentication is a major part of the authentication workflow and provides a human language interface and user interplay, with which users are very familiar. All forms of two-factor authentication should be supported as well, like SMS OTPs, Telephony OTPs, Soft Tokens, Hard Tokens, NFC, and X.509.

4. Logging from HTML5 resources. Logging and reporting are essential to any security solution. It is vital to track all events concerning user authentication, authorization, and data access to ensure that only the permitted users are entering corporate applications at any time.

5. Application deployment and access. This system should be in place for app-to-role deployment and include an inventory of all deployments, which should be the same type of access control the enterprise has been running for the enterprise apps. The solution should include one-touch resource allowance/revocation.

6. Data management of HTML5 apps. Data management should determine how to “wipe” data from an application and the data space for an app.

7. Integration. If enterprises try to piecemeal these solutions together, it becomes a nightmare. URL-based access control has been around for over 20 years. Look for the solution that can amalgamate multiple directories, providing multiple two-factor options and SSO into HTML5 apps and other app and IT resources.  

The solution for multi-device deployment is HTML5. Now, let’s deploy it right for the enterprise. 

Garret Grajek is a CISSP-certified security engineer with more than 20 years of experience in the information security and authentication space. As Chief Technical Officer and Chief Operating Officer for SecureAuth Corp., Garret is responsible for the company's identity ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
6/9/2014 | 10:00:06 AM
Good breakdown on using how to use HTML5 securely for MDM
Good blog, Garret. In this early adoption phase, what strategies are you seeing that are most effective. And on the flip side, what are some common errors. 

Best/worst war stories from Dark Reading community members are welcome, as always.
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading Must Reads - September 25, 2014
Dark Reading's new Must Reads is a compendium of our best recent coverage of identity and access management. Learn about access control in the age of HTML5, how to improve authentication, why Active Directory is dead, and more.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-5619
Published: 2014-09-29
The Sleuth Kit (TSK) 4.0.1 does not properly handle "." (dotfile) file system entries in FAT file systems and other file systems for which . is not a reserved name, which allows local users to hide activities it more difficult to conduct forensics activities, as demonstrated by Flame.

CVE-2012-5621
Published: 2014-09-29
lib/engine/components/opal/opal-call.cpp in ekiga before 4.0.0 allows remote attackers to cause a denial of service (crash) via an OPAL connection with a party name that contains invalid UTF-8 strings.

CVE-2012-6107
Published: 2014-09-29
Apache Axis2/C does not verify that the server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate.

CVE-2012-6110
Published: 2014-09-29
bcron-exec in bcron before 0.10 does not close file descriptors associated with temporary files when running a cron job, which allows local users to modify job files and send spam messages by accessing an open file descriptor.

CVE-2013-1874
Published: 2014-09-29
Untrusted search path vulnerability in csi in Chicken before 4.8.2 allows local users to execute arbitrary code via a Trojan horse .csirc in the current working directory.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
In our next Dark Reading Radio broadcast, we’ll take a close look at some of the latest research and practices in application security.