Limiting Access To Services Based On Identity Or Role

Work Completed By: Andy McGarry

DESCRIPTION

This project is concerned with showing how we can control access to services base on an individual’s identity, using a consistent method despite the services originating form different sources.

For a group of at least three services, from different providers, show how an application or identity framework can allow/prevent access to these services for a set of four different identities.

The solution should be entirely web based and include some form of secure authentication involving more than one factor.

DETAILS/LOCATION OF PRACTICAL DEMONSTRABLE OUTPUT

Details of where code, web pages etc can be found.

Snapshots of the Ubuntu appliances complete with working RP and OP code can be found in the Strategy R&D area.

PROJECT OUTCOME

Describe the degree to which the work was successful in addressing the project description. Include reasons why or why not.

Introduction

Security administration can be costly and prone to error because administrators usually specify access control lists for each user on the system individually. With Role Based Access Control (RBAC), security is managed at a level that corresponds closely to the organization's structure. Each user is assigned one or more roles, and each role is assigned one or more privileges that are permitted to users in that role. Security administration with RBAC consists of determining the operations that must be executed by persons in particular jobs, and assigning employees to the proper roles. Complexities introduced by mutually exclusive roles or role hierarchies are handled by the RBAC software, making security administration easier.

Service-based Identity and Access Management - The Rise of SOA-Centric Identity
http://www.ebizq.net/webinars/8487.html

Not all access is from employees of the organisation, they could be members of the public, customers, contractors, consultants of members of partner organisations

Research

After looking at authentication frameworks such as OpenID, Suns Metro/Glassfish, Microsofts Geneva and OAuth, and also looking at services which use some of these such as Yammer (OAuth) and Google (OpenID, OAuth) I realised that there is tremendous choice. However limitations exist with in these frameworks, within the services and the interactions between them. No off-the-shelf framework-service combinations existed to allow the full exploration of this projects objectives That is namely using different services with different providers and show role based access to them using different levels of authentication.

Real World Issues

Of course when you are building an infrastructure which requires limited access based on rolebased access then you really need control over the service and authentication framework. This can easily be done using open standards and building your own environment of identity provider and services. Test users can now be used to demonstrate the objectives.

However the different aspects of authentication are not readily available in one solution (authentication framework, level of access, compatible service, and optional two factor solution). In order to attain focus the level of authentication will be simulated (actual integration and demonstration is appropriate for a later project extending this one).

Choices

In order to be in control of both the authentication framework (provider) and the service (receiving party) I settled on using open standards to allow me to build my own environment. I chose to use OpenID because of is relative maturity and example code for Ruby on Rails exists. The appendices show the research I did into other environments such as Google, SUN and Microsoft.

Ruby on Rails was chosen as the application framework because code can be changed without compilation, it is mostly platform indipendant, the server does not need restarting after a change and because of its marvelous integration with web servers, database servers and html pages.

The Approach

Building VM Test Environment using Software Appliances
My development environment is a powerful HP (Core2Duo 2.4GHz 3GB RAM 300GB disc) laptop installed with WMware Workstation 6.5.
Appliances are pre-made software images of servers complete with installed components. In order to speed up R&D I sought out pre-made server images which would eventually host the OpenID OP and RP services – I chose to use a TurnKey appliance of Ubuntu Server 8.04 configured with Apache2, Ruby 1.8.6, MySQL 2.7, Perl, Gem 1.3.1 and Rails 2.3.2. I had found downloadable example OpenID RP and OP code in Ruby/Rails from http://openidenabled.com/ruby-openid/.

Some appliance vendor choices are:
http://www.jumpbox.com/app/rubyonrails
http://www.vmware.com/appliances/
http://www.turnkeylinux.org/
Note: Some appliances are free but others are by subscription. It is easy to create your own appliances.

Advantages of using appliances:
• Speed (pre configured with software for a tailored task) – no installing to do.
• Choice – wide variety of tailored appliances available.
• Standardisation – servers are consistent.
• Management – built in management tools (e.g. web based).
• Inclusion of VM or Cloud tools and utilities – ready to go for web deployment.
• Subscription services – your appliances are automatically kept patched and up to date with latest versions etc.

Developing a Demo

Due to the short time period for this project the demo needed a good starting point (use reference code) and be quick to install, develop and test and have extensive documentation.

I downloaded files from the OpenIDEnabled website mentioned above: H:\ISS\Strategy\StrategyArchitecture&Planning\R&D\R&D Tools and Installers\OpenID for Rails

There was a lot of work to get the example code to work due to errors in the code and vast ommissions from the instructions. A comprehensive posting to JanRain mailing list did not help. Finally after much fixing and learning plus help from others in the Strategy Team (Tim and Steve) the example code was fully working.

This was then extensively modified to provide the demonstartable features required for this project.

The Outcome

The OpenID Server (Provider) can register and log users in. When registering a user it can be recorded (using radio buttons in the interface) which role they will have on each of the three test Relying Parties (Consumers). The roles (for simplicity) are just "user" and "admin".

The Provider can also simulate the login method (also using a radio button selection) from password, anti-phising, two-factor or physical-two-factor. The selection is encoded using PAPE and the information returned to the requesting Consumer.

The Consumer can then act on this information locally (e.g. user denied because they only authenticated using a password and not a token).

The Consumer displays a page describing the status of the authentication (yes, no) and when level of access has been granted (user, admin). Other information provided by the OP is also displayed (fullname, email address etc) to show information can be passed and that the Consumer could act on it if required.

SHORT TERM BENEFITS

What immediate impact could the output of this R&D work have on the organisation – could it provide benefits without compromising our strategic approach?

Understanding

  • The importance of developing a federated identity hub using open standards.
  • An up to date and deeper understanding of the latest OpenID framework and its extensions.
  • An understanding of the benefits of using system software appliances.

Linking to Other Strategy Work

  • The demo system could be shown to work in the experimental WCC Amazon Cloud being developed for the Infrastructure stream of Strategy.
  • The Relying Party (Consumer) code could also be integrated into a proper application (such as WordPress) to demostrate how rolebased access can make a difference.
  • The OpenID Provider code could be integrated with open SMS OTP code (via an SMS gateway) to demonstrate PAPE providing two-factor authentication (this was simply simulated in the demo RP and OP developed for this project).

STRATEGIC IMPLICATIONS

How the work carried out fits with our strategic direction or how it should contribute to our strategic thinking.

The Benefits

In owning the Identity Provider and having the correct compatibility support in the service / application real benefits for federated authentication and identity can be realised with existing open technology. Both internal users and external users can be supported. External users (the public) can use existing IDs or register and use one directly with the local authority (a big advantage over Me@WCC).

Easy to extend access to partner organisations or even share full control if appropriate.

Real control over access can be realised. An admin user for a service could log in with just a password and just have normal user priviledges but if they logged in with a two-factor token would be granted their full admin rights.

Centralisation of identity leads to greater security and control of services and users. A user can be quickly enabled or disabled in one place. Support costs and training can be reduced. Audit trails and logging can be holistically reported.

Control

  • Staff and Public can be differentiated.
  • Levels of access, visibility or responsibility can be provided appropriately.
  • Support for different authentication frameworks can be integrated as and when required (e.g. OAuth for Yammer etc).
  • Application and Services can request different levels of authentication, respond to different levels of access, recognise different identity providers and react specifically (e.g. allow greater access if WCC provider or reject from other providers etc).

Software appliances (third-party or home-grown) could be widely used to ensure the basis of the Cloud Environment is automatically kept up to date (OS and application patches, security updates, application upgrades, system configuration etc).

OTHER NOTES ETC

Appendix A: OpenID Supporting Research

Exploring Two Factor and OpenID

MyOpenID and Two Factor (CallVerifID)

OpenID offers some interesting additional services one being an official solution for two-factor authentication using the OOB-outbound ticket-response technique (when you attempt to login you get a phone call to your mobile which you respond to via either a PIN or # key): https://www.myopenid.com/about_callverifid

Enhanced security for OpenID

CallVerifID™ provides the most convenient and cost-effective strong security measure available for OpenID users. An individual can enable CallVerifID™ within seconds to add an additional authentication factor.
• Easy two-factor authentication for myOpenID
• Instantly receive a call when signing into myOpenID. Simply answer and press # to authenticate.
• No extra phone capabilities or text messages. Use any phone.
The CallVerifID™ service is powered by PhoneFactor, a recognized leader in phone-based authentication services.
CallVerifID™ is available in 30 countries.

Authentication Framework Convergence: RPX

One serious attempt at making websites use OpenID easily as a service is: https://rpxnow.com/ providing a defacto user experience and application of OpenID and OAuth. RPX is not a service but a technology which can be integrated into your service (website). RPX is endorsed by the wider OpenID community.

RPX makes it easy to add OpenID and other authentication APIs to your website. We help you add authentication from providers like Google, Facebook, Twitter, Yahoo! and Windows Live ID, making it extremely simple for users to get in and start using your web application. It runs on our servers in the cloud and is accessed via simple, restful API calls. RPX is a proxy between your website and the OpenID provider, and is completely transparent to the end user. The service looks like this from a very high level:

rpx-basic-highlevel2.png

Adding RPX to your website doesn't require any changes to your database, and its only requirements are the ability for your servers to make outbound HTTPS calls and to parse JSON or XML.

Note: Of concern is the current lack of support for PAPE in RPX.

Exploring OpenID API and Extensions

OpenID Provider Authentication Policy Extension 1.0 - Draft 7 (PAPE)

http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-07.html
This extension to the OpenID Authentication protocol provides a mechanism by which a Relying Party can request that particular authentication policies be applied by the OpenID Provider when authenticating an End User. This extension also provides a mechanism by which an OpenID Provider may inform a Relying Party which authentication policies were used. Thus a Relying Party can request that the End User authenticate, for example, using a phishing-resistant or multi-factor authentication method (e.g. 2 factor token).

This extension also provides a mechanism by which a Relying Party can request that the OpenID Provider communicate the levels of authentication used, as defined within one or more sets of requested custom Assurance Levels, and for the OpenID Provider to communicate the levels used.

This extension is not intended to provide all information regarding the quality of an OpenID Authentication assertion. Rather, it is designed to be balanced with information the Relying Party already has with regard to the OpenID Provider and the level of trust it places in it. If additional information is needed about processes such as new End User enrollment on the OpenID Provider, such information should either be transmitted out-of-band or in other extensions such as OpenID Attribute Exchange. Other aspects (e.g. security characteristics, credential provisioning, etc) could be dealt with in the future.

This extension is optional, though its use is certainly recommended. This extension can be used with OpenID Authentication versions 1.1 and 2.0. http://openid.net/specs/openid-authentication-2_0.html
While none of the information transmitted using this extension can be verified by the Relying Party using technology alone, this does not limit the utility of this extension. Because there is no trust model specified by OpenID, Relying Parties must decide for themselves which Providers are trustworthy; likewise, RPs can decide whether to trust authentication policy claims from such OpenID Providers as well. As with other OpenID extensions, it is the Relying Party's responsibility to implement policy relative to the OpenID Provider's response.

OpenID Technical Documentation

• OpenID Authentication http://wiki.openid.net/OpenID_Authentication_2
• Simple Registration (SREG) http://openid.net/specs/openid-simple-registration-extension-1_0.html
• Attribute Exchange (AX) http://openid.net/specs/openid-attribute-exchange-1_0.html
• PAPE (Provider Authentication Policy Extension) http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-07.html

OpenID Extensions: These extensions are currently being developed:

• User Interface http://wiki.openid.net/OpenID-User-Interface-Work-Group-Proposal
• Contract Exchange http://wiki.openid.net/Contract-Exchange
• OpenID-OAuth Hybrid http://wiki.openid.net/OpenID-and-OAuth-Hybrid-Extension
• Services and Metadata Discovery http://wiki.openid.net/OpenID-Services-and-Metadata-Discovery-Coordination

Appendix B: SUN JAVA and Web Based Services

SUN Java: Building Identity-Enabled Web Services
http://developers.sun.com/identity/reference/techart/id-enabled-ws.html

SUN Java: Metro and GlassFish Web Services Overview
http://java.sun.com/webservices/index.jsp

GlassFish Web Space Server

Sun's next-generation portal server platform, Glassfish Web Space Server enables businesses to pull together applications and content from Web-based and internal sources and present them as a unified, customizable portal on browsers, kiosks, and mobile devices.

Sun Identity Manager 8.1

Sun Identity Manager is the first user-provisioning software to truly provide role-based user provisioning, enabling customers to use business roles for both identity lifecycle management and identity auditing across enterprise and extranet environments.

Java Application Platform SDK

Streamline enterprise application development and improve developer productivity. The SDK supports Java SE 6 and includes Open ESB, Sun Java System Access Manager, Portlet Container, and Web Services for Remote Portlets (WSRP).

Sun Metro & GlassFish

Transitioning from Java WSDP to Project GlassFish

Web services are Web based applications that use open, XML-based standards and transport protocols to exchange data with clients. Web services are developed using Java Technology APIs and tools provided by an integrated Web Services Stack called Metro. The Metro stack consisting of JAX-WS, JAXB, and WSIT, enable you to create and deploy secure, reliable, transactional, interoperable Web services and clients. The Metro stack is part of Project Metro and as part of GlassFish, Java Platform, Enterprise Edition (Java EE), and partially in Java PlatForm, Standard Edition (Java SE). GlassFish and Java EE also support the legacy JAX-RPC APIs.

Project GlassFish replaces the Java Web Services Developer Pack, our previous release vehicle for providing new web services between releases of the Sun Java System Application Server.

At the 2006 JavaOne conference in San Francisco, Sun began delivering on the promise of Project GlassFish. Sun is now offering visibly developed, community-based, open-source implementations of a Java EE 5-compliant application server. This open-source implementation includes open-source implementations of all of component technologies in the Java Web Services Developer Pack. The advantages that Project GlassFish offers to Web services developers are sufficiently substantial to warrant a major transition. namely, that the Java Web Services Developer Pack will no longer be developed as a discrete release vehicle for the Web services and XML technologies that the Java WSDP shares with Project GlassFish.

This transition deprives Web services developers of nothing. Instead, developers can retrieve not only the semi-annual snapshots of Web services and XML technologies that the Java WSDP provided but also those same technologies at the latest (or any previous) state of development needed. Like the Java WSDP, the open-source Java EE 5-compliant application server and any of its component technologies are available freely. And as Project GlassFish components, the Web servces and XML technologies come with consistent licensing that is simpler and more accommodating of a wider range of uses. Over the years of the Java WSDP's availability, developers have frequently expressed the wish for clearer licensing, and Project GlassFish addresses this wish and enables easy adoption.

Moreover, the integration of components that Java WSDP users enjoyed is also a feature of the Project GlassFish milestone builds, so developers can easily make sure they are using the correct technology components in their Web services projects.

The Java WSDP 2.0 currently remains available for download, but perhaps now is the time for developers to make the switch to Project GlassFish for the latest versions of Java Web services and XML technologies.

The Basics

Why Metro https://metro.dev.java.net/
The Metro Web Services stack delivers secure, reliable, transactional interoperability between Java EE and .Net 3.0 to help you build, deploy, and maintain Composite Applications for your Service Oriented Architecture. Metro provides ease-of-development features, support for W3C and WS-I standards such as SOAP and WSDL, asynchronous client and server, and databinding through JAXB 2.0.

Why GlassFish https://glassfish.dev.java.net/
GlassFish is an open source, production-quality and Java EE5 compatible application server. GlassFish focuses on ease-of-development with enhanced web services via Metro. Constructing web applications is made easier with JavaServer Faces (JSF) technology and the JSP Standard Tag Library (JSTL). Java EE 5 supports rich thin-client technologies such as AJAX, technologies that are crucial for building applications for Web 2.0.

Appendix C: Microsoft Geneva, .Net and Web Based Services

"Geneva" Simplifies User Access to Applications and Services
http://msdn.microsoft.com/en-us/security/aa570351.aspx

Using Role-Based Security with Web Services Enhancements 2.0 (Microsoft .Net)
http://msdn.microsoft.com/en-us/library/ms996950.aspx

Appendix D: Google Apps and Web Based Services

What are the Google Account APIs?

The Google Account APIs allow third-party applications to get limited access to a user's Google account for certain types of activity. All requests for access must be approved by the Google account holder. Currently the Account APIs cover authentication for these activities:
• Exchange user data between third-party apps and Google services
• Let users log into third-party apps using their Google account

The Google Account APIs streamline the authentication process for third-party applications by providing a mechanism for requesting and receiving authentication. Many Google APIs support the Account services, including those based on the Google Data APIs http://code.google.com/apis/gdata/.
http://code.google.com/apis/accounts/

Boost productivity with Google-powered collaboration apps
Information access control – Each piece of content can be as private or as public as necessary.
http://www.google.com/apps/intl/en/business/collaboration.html#utm_medium=et&utm_source=sites-en-ui&utm_campaign=crossnav

Federated Login for Google Account Users
http://code.google.com/apis/accounts/docs/OpenID.html

Appendix E: Open Standards and Generic Role Based Identity

Role-based access control
http://en.wikipedia.org/wiki/Role-based_access_control

NIST: Role Based Access Control (RBAC) and Role Based Security
http://csrc.nist.gov/groups/SNS/rbac/

The Yammer API (Uses Oauth for authentication) Example code in Ruby, c#, Perl, PHP and access requests in XML for the various Yammer functions.
http://www.yammer.com/company/api

RESTful Authentication for the Social Web

We describe a simple protocol for RESTful authentication, using widely deployed technologies such as HTTP, SSL/TLS and Semantic Web vocabularies. This protocol can be used for one-click sign-on to web sites using existing browsers — requiring the user to enter neither an identifier nor a password. Upon this, distributed, open yet secure social networks and applications can be built. After summarizing each of these technologies and how they come together in FOAF+SSL, we describe declaratively the reasoning of a server in its authentication decision. Finally, we compare this protocol to others in the same space.
http://blogs.sun.com/bblfish/entry/foaf_ssl_restful_authentication_for

Information Card

OpenID Foundation and Information Card Foundation publish vision for open government through open identity technologies
Posted at 9:00 am on August 13, 2009 by Chris Messina
http://openid.net/2009/08/13/openid-foundation-and-information-card-foundation-publish-vision-for-open-government-through-open-identity-technologies/

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License