Step-up authentication as-a-service for SURFnet

Two-factor authentication used to be the domain of secret services and the military. The enterprise and consumer e-Banking and e-Government domains have since embraced two-factor (or: step-up) authentication. More recently social network sites such as Facebook and Google have started offering two-factor to protect their (free) services. Federations of higher education and research (operated by the NRENs) are still largely basing their authentication on username/password.

A parallel development is that service providers in federations for higher education and research are starting to offer services that deal with highly sensitive information; for instance privacy sensitive administrative, research, or medical data. This is both a consequence of the success story of federations as well as the "move to the cloud" where traditional in-house applications like accounting systems are increasingly being outsourced to cloud providers. Because of the sensitive nature of the data in such systems, stronger forms of authentication are necessary.

NRENs such as SURFnet have noticed these trends, and the discussion of how to best approach two-factor within a federated setting is now in full progress. An Identity Provider (IdP) within a federation is ultimately responsible for providing the identity of its users. This includes authentication and the IdP can make authentication as strong as it wishes, of course. The case for two-factor in a true federation is, however, significantly more complex than rolling out two-factor in a situation where Identity Provider and Service Provider coincide (such as in e-Banking or the enterprise), as information about the Level of Assurance is shared with and interpreted by Service Providers in the federation. Introducing multi-factor authentication within a federation is really only sensible if registration (enrollment of an authentication token) procedures also warrant a strict higher level of assurance.

Novay, in close collaboration with SURFnet, has made an initial design for a service to assist Identity Providers in the introduction of two-factor authentication solutions that can be used across the SURFconext federation. The report describing the design is available for download from the SURFnet website. The report describes both the technical (architecture, standards) and the procedural (registration, logging, de-registration) challenges.

Architecture

The two main architectural challenges to focus on are:

• the best location for a multi-factor-authentication service, such that it can support multiple Identity Providers;
• which standards (and what choices within those standards) should be used for uniformly signaling the level of assurance from Identity Providers to Service Providers.

As for the location of the service: in a SAML based hub-and-spoke federation (such as SURFconext) it makes sense to base (the initial version of) the service as a transparent proxy on the Service Provider bound exit of the hub (as shown above). This separates the service from the hub. It also means that the Identity Providers and Service Providers can remain unchanged, except for Service Providers that need to deal with higher levels of authentication. The paper builds a case for this simple architecture.

As for the standards to use: there are many variations on levels of assurance frameworks. To name  just a few: NIST SP800-63 for the US and STORK for the EU. The best option, at this moment, would be to standardize on the upcoming ISO/IEC 29115 standard which will unify some of these standards. SAML 2.0 has had support for signaling details about the authentication process (and related processes) since its inception in the form of the so-called Authentication Context. This concept, however, leaves a lot of implementation freedom (and therefore interpretation freedom) for Identity Providers and Service Providers. Attempts to merge the Authentication Context concept with ISO 29115-style levels of assurance are relatively recent, and also appear in other authentication protocols such as OpenID Connect. The paper will give recommendations for how to best apply these standards.

Registration process

The level of assurance of an authentication token is not only determined by characteristics of the token itself, but also by the process by which the token is bound to an individual user by the Identity  Provider. The paper recommends appointing a Registration Authority within the institute of higher education or research and making that person responsible for binding authentication tokens to users  (staff, students) of the institute. The paper gives precise guidelines for setting up a Registration Authority. The most important recommendation is that individual users should visit the Registration Authority in person for face-to-face binding to the authentication token. The user should bring the token and a valid passport or identity card. The Registration Authority will check that these match with the user and with the attributes as issued by the Identity Provider. The Registration Authority also oversees an authentication attempt (with the second factor only) to make sure the user actually  controls the token.

The registration process is supported by an online service hosted by the federation operator. The service contains both a self-service user interface for end-users (so that most of the administrative process can be dealt with before the user actually visits the Registration Authority) as well as a user  interface for the Registration Authority. The paper shows mock-ups for both user-interfaces.

It is highly likely that the service proposed in the paper has broader applications beyond the boundaries of SURFconext. The architecture was described with portability in mind, such that the service can be re-used in other federations. Although the paper makes some concrete choices (to make it relatively easy to actually start building such a service) these choices are documented in the  paper.

Acknowledgements

The authors would like to acknowledge Ruud Kosman of Novay for designing the mock-ups and other colleagues from SURFnet and Novay for reviewing early drafts of the paper.

Context-enhanced Authorization

Context information can make authorization management more flexible and more secure. Knowing when and where users are, and what they are up to helps in determining which access rules to apply. We recently did a project with Rabobank and IBM where we ask (and answer) questions such as: 

• What authorization related use-cases could benefit from context information?
• Which context-sources are relevant, mature enough, secure enough to be used today (or in the very near future)?
• How to deal with the (lack of) quality and authenticity of context?
• How does context information interact with authorization standards such as XACML and today's implementations of those standards? (See my previous posts for more technical details on the hands-on XACML work that we did in that project.)

The main lessons learned (the answers to the above questions) are:

• Typical use-cases can be found in the area of the mobile workforce ("nomadic working", etc.). As organizations introduce these new ways of working, traditional security policies that are only based on (authenticated) identity and static roles and entitlements are too strict and too coarse-grained. Context can make a difference here and allows finer-grained access so that, for example, medium level security tasks can be performed from home if the context allows this.
• A model for context-information can be constructed around different context-types, some traditional (location, time, ...), some more exotic (physiological, mental, social, ...). The above use-cases can already be adressed with the more traditional context-sources: location, time, proximity, device id, network id. These basic context-sources are readily available, and are under control of the organization.
• The easiest way to deal with authenticity and quality of context is to rely on trusted context-sources that are under control of the organization.
• Externalization of authorization, such as propagated by the Attribute Based Access Control (ABAC) paradigm (and facilitated by standards such as XACML) works well in practice when combined with context information. In a demonstrator (see video above) we showed that adding context to authorization policies managed by Tivoli Security Policy Manager (a XACML IBM product) comes down to adding a policy information point. Relying applications only need to understand XACML in order to become context-enabled.

Obviously, there are questions left for future research. How to deal with privacy issues is one of them. Complexity of policies and other scalability and performance issues form another. Want to read more? Go check out the project page or read the white paper.

XACML with Tivoli Security Policy Manager - Part 2

(This is part 2, for installation & configuration see part 1)


Using the TIP to specify services
TSPM needs to have a model of the resources that need protection (collections of resources are called services in the TSPM documentation). Rather than an unstructured bag of resources, a service in TSPM is specified as a tree of labeled nodes. Services can be created by hand using the web-based editor inside the TIP, or can be imported from other descriptions of applications.

An example of a supported description language for importing services is WSDL. It is relatively easy to start protecting web services in this way, just point TIP towards your WSDL file (it even supports multi-part WSDL including schemas). The resulting application model consists of the web methods of the web service (as resources). A PEP can then try to access these resources using the "invoke" action.


Using the TIP to specify policies

Policies can be created using the web-based structure editor inside the TIP. A policy can be attached nodes of a service, and the policy then holds for that node and all child-nodes of that node.

A policy built in the editor is series of rules connected using "else-if" connectives. Each rule consists of elementary propositions formed by comparing an attribute with a value of approprate type, connected using "or" and "and" connectives.

The web based nature of the structure editor forces it to be simple. Policies, perhaps created using some other editor, can also be imported as long as they are in XACML format. And, of course, polcies can be exported.

Writing a custom PEP
To test an installed and registered RTSS just use the authorization web service. Hand-craft a XACML request and send it using curl:

curl --basic -u "wasadmin:waspassword" --header "Content-type: text/xml;charset=UTF-8" --header "SOAPAction: http://xacml.ws.authz.rtss.tscc.ibm.com/rtss/AuthzService/XACML" --data "@request.xml" "http://tspm:9080/rtss/authz/services/AuthzService"

(Where a file request.xml holds the XACML request.) Note that the service uses basic authentication. The same web service is also exposed on an https port, allowing mutual TLS authentication (and possibly fallback basic authentication to authenticate the client). The request to send needs an environment section with a "ContextId" attribute, and issuer "http://security.tivoli.ibm.com/policy/distribution". The resource section of the request refers to identifiers of the nodes in the service (as specified via TIP as above).

Based on the WSDL of TSPM's authorization service you can also create a custom PEP client with JAX-WS.

An alternative to write a custom PEP in Java is to use the JACC+ API provided by IBM. This API implements (and extends) the Java Authorization Contract for Containers (JSR-115). The resulting Java code will be at a slightly higher level of abstraction, but this PEP needs an instance of RTSSClient (and thus needs to run inside WAS). You'll need the com.ibm.sec.authz.jaccplus_7.3.jar that came with RTSSClient and the javax.j2ee.jacc.jar (or stubs thereof) to compile your war.

Writing a custom PIP
A policy information point (PIP) provides values for attributes that are not part of the request sent by the PEP. TSPM has some environment attributes pre-configured (e.g. time of day, date), an external PIP allows to add other environment attributes. A custom PIP needs to implement the IExternalFinder interface and needs to be packaged as an OSGi module (which comes down to including a 3-line plugin.xml in the jar) and needs to be registered (which comes down to adding some lines to the security-services.xmi file on the WAS and running an osgiCfgInit.sh script).

Conclusion
This is not a product review! (so these are just some observations...)

• Configuring IBM Tivoli Security Policy Manager, and the stack of technologies it depends on, is, doable yet by no means trivial (for a beginner). It gets easier though, after a couple installation attempts.
• Implementing XACML support into external applications (essentially implementing a PEP interface), on the other hand, turned out to be simpler than expected.
• The same holds for implementing a PIP interface.
• The web-based editors in TIP for services and policies were ok for our purposes, yet may be a bit limited when dealing with complex services and policies