In many countries, when new areas were being settled, there was a key requirement to establish the rule of law and to implement an enforcer of the rules, someone who could immediately be identified and whose authority went unquestioned. The new frontier of "consumer-facing" Web 2.0 applications are now making headway into the enterprise, and with them come new security concerns that must be addressed, just as the new settlements required their own security measures.
More and more businesses are actively injecting Web 2.0 technologies into new and existing applications to better serve their employees, partners and customers. Examples include community applications and forums that allow customers to contribute and participate in product ratings and reviews. Businesses deploying these applications require security enforcement so that this key information doesn't get altered by malicious intruders or intercepted by competitors. These companies require a new sheriff to watch over their critical information.
In fact, with the adoption of Web 2.0 in the enterprise, it becomes imperative that applications are designed to address not only the same standards, security issues and architectural considerations as any other enterprise-class application, but also the new security concerns specific to Web 2.0 technology.
With the early stagecoach carriers, there was significant concern around highwaymen who posed a threat to the successful delivery and retrieval of precious cargo. Therefore, escorts were often hired to accompany and protect the stagecoach from unwanted interventions.
Enterprise Web 2.0 applications utilize the same rich UI technologies as their counterpart applications in the consumer space. Using technologies such as AJAX, developers can create a rich UI experience by leveraging the XMLHttpRequest API (application programming interface) to request a URL without refreshing the browser page. Such highly dynamic applications have greater security risks than typical Web applications, where the interaction between the presentation layer and the back-end server(s) is controlled to some extent. However, these new Web 2.0 applications still need to ensure that no unwanted highwaymen attacks are injected. In the same way, applications built using technologies such as JSON are prone to JSON hijacking, which builds on CSRF (cross-site request forgery) to allow a malicious "service" to intercept data. In an application with a lot of functionality built into the presentation layer, it is typical for designers to implement security checks on the client side without having additional access-control checks on the server side.
In many countries, the highest local law-enforcement agent was considered to be the sheriff or the high sheriff. The sheriff was often charged with enforcing the law of the land as it applied to his part of the country. If anyone failed to follow these rules, they were quickly removed from society at large.
Typical enterprise applications benefit from the addition of Web 2.0 services. For example, in order to resolve a help ticket, a customer-service representative can use a Web 2.0-style application to create an ad hoc community and invite the necessary participants to collaborate and resolve the issue. This type of community could use a multitude of services, including discussion forums and wikis where participants can share ideas and provide feedback; content services that enable sharing and publishing documents; and tagging services that help classify, share and find information. Much like the sheriff, each service should be responsible for protecting the resources and information it exposes. Thus, it is important that security be enforced at the individual service layer.
It is recommended that developers leverage frameworks that help build and assemble the services and the content they expose on the server side, thereby providing server-side components that act as a proxy to the various services. Placing policy enforcement on the server side frees the UI developer from putting authorization calls in the UI layer, and — more importantly — lets developers utilize the various server-side frameworks for security enforcement.
In the U.S., there were times when one sheriff expected another sheriff to carry out duties on the border between two states. To have one overall owner, a federal marshall was put in place. The federal marshall's duties involved ensuring uniform enforcement across all states within the country.
Web 2.0 enterprise applications typically consume APIs or Web-service interfaces to interact with services hosted by internal or partner applications. These Web services, which may transmit confidential data, are prone to attacks such as parameter manipulation, where the parameters in the SOAP message are manipulated to inject SQL, XPath (XML Path Language) and shell scripts. Therefore, it is important to ensure that the messages flowing between the consuming application and the service are not tampered with. Transport-level security using SSL (Secure Sockets Layer) and message-level security using WS-Security (Web Services Security) are both imperative. XML encryption must also be leveraged to maintain data confidentiality, and the service's authenticity and integrity should be ensured using the XML signature. The enterprise application should ensure the kind of token profile — username with optional password digest, SAML (Security Application Markup Language) token and others — supported by the service and include it as part of the SOAP header. WS-Trust-based solutions can also be used where trust must be brokered between partner applications. Developers can use certain frameworks to implement agents (serving as policy-enforcement points) that can execute against inbound and outbound Web-service calls without affecting the logic of the service. Such frameworks can provide a decentralized platform for configuring policies across services and proactively managing the services being consumed by the application.
With all the different law-enforcement agents, it became evident that a standard way of identifying these individuals was required. In this way, a badge or a star and a relative hierarchy for jurisdiction became necessary to ensure that everyone involved understood each other's role. And as new counties were settled, the sheriff became a basic official to be hired or elected.
The RBAC (role-based access control) model is designed to protect privileged resources based on a user's role in the enterprise. Because it reduces the complexity and cost of security provisioning, RBAC is the most prevalent permission model in enterprise applications today. The "resources" protected using RBAC are mostly created and managed by the administrator of the enterprise application. However, enterprise applications also have to deal with the access-control models and implementations of the various participating services. The roles and policy definitions of these services may conform to different schemas and be different from those of the enterprise application. For example, if an enterprise application consumes a service that provides content-management features, a user with a "viewer" role in the application will have a "reader" role in the content-management back end. The implementer would thus need to create a new permission model that mapped application roles to service roles, so that any user who is granted a "viewer" role in the application is given the corresponding "reader" role on the content-management system. Therefore, a contract (SPI/API) needs to be established between the application and the participating services to facilitate this new permission model so that the user has all the access-control privileges needed to use the application in a coherent way — just as new sheriffs were elected when new counties are established.
The distributed nature of services consumed by Web 2.0 applications imposes further requirements on existing identity-management solutions. A service may house its own identity-management store and use a totally different authentication model than the fronting application. A user may have different identities and credentials in the application's identity store and the service's back-end identity store. Credentials for identities need to be mapped using secure credential stores, or identities should be asserted using WS-Security token profiles in case the services expose Web-service interfaces.
There are oftentimes too many people for any one sheriff to police. As a result, the sheriff must nominate a deputy to take on the role of enforcer.
Since most Web 2.0-based applications are collaborative in nature and revolve around user-generated content, it is important that access control at times be based on user-profile attributes rather than just user roles. The authorization checks should also consider the context in which the request to access a resource is being made. Such authorization schemes can help administrators manage privileged actions — such as deleting a project page from a wiki — at a more granular level, similar to the way a deputy would assume the sheriff's duties.
Enterprise employees have begun to ask why it is easy to accomplish tasks and collaborate on problems on the Internet but not in the workplace. In response, organizations have begun to introduce collaborative Web 2.0 capabilities to enterprise applications. As more companies add these services and technologies to new and existing applications, a new sheriff needs to be implemented to ensure that the information is protected from modern-day highwaymen and hackers alike. Using some of the best practices described in this article will help ensure the successful use and deployment of these enhanced Web 2.0 capabilities.
Manish Devgan is a principal member of technical staff at Oracle Corp. and Vince Casarez is VP of product management at Oracle.
In the 1980s and 1990s, business applications and data were largely confined within and protected by a Local Area Network (LAN). The 2000s introduced a significant change. Download this white paper now to learn why the shift to the cloud is changing how companies think about and manage their IT infrastructure. more
Microsoft moved to the cloud in 2014, and, as a result, Office 365 is taking off. Now, Okta customers are connecting to Office 365 in increasing numbers. This eGuide explains why IT departments should plan and deploy solutions around identity and mobility management in concert with their Office 365 roll out to get maximum user adoption. more
For most companies, Active Directory (AD) or Lightweight Directory Access Protocol (LDAP) play a central role in coordinating identity and access management policies. When on-premise applications are integrated to Active Directory or LDAP, users get the best possible experience. That's why Okta's cloud-based identity and access management service provides a highly useful single integration point. more
With more and more businesses adopting Software-as-a-Service (SaaS) applications, enterprise IT is fundamentally changing. This whitepaper presents the eight biggest Identity and Access Management (IAM) challenges associated with adopting and deploying cloud and SaaS applications, and discusses best practices for addressing each of them. more