Managing Incident Response in Identity Federations

In talking with service providers at this week’s conferences on federated access management in Helsinki it’s become apparent that many of them are asking identity providers to supply not only the information that they need for normal operations, but also information that will only actually be needed if a problem occurs. For example it seems that some service providers may request every user’s real name just in case a user mis-behaves and breaks the service provider’s policy.

Since most service providers won’t have a direct relationship with their users - indeed the service provider and user are increasingly likely to be in different countries - there’s probably a better way to deal with problems. The identity provider, who is likely to have a contract or other agreement with their student or member of staff, is much more likely to be able to talk to them face-to-face and, if necessary, impose a punishment for misbehaviour. And if the identity provider agrees to deal with problems there may be no need for every user’s real identity to be disclosed every time they access a service; indeed it may not even be necessary to disclose it if a particular user mis-behaves so long as the service provider trusts the identity provider to work out which user caused the problem and deal effectively with them.

This approach has been used for many years with federated network access under the Janet eduroam policy. Each time a user is authenticated their home organisation passes a session identifier to the visited organisation; if the user causes problems then the visited organisation can report the relevant log extracts and the identifier and the home organisation is obliged by the policy to deal with the user as if they had breached their Acceptable Use Policy at home. The policy thereby reassures organisations offering visitor services that problem users will be dealt with, while protecting the privacy of every user of eduroam. Stefan Winter of RESTENA gave a presentation on how to trace a mis-user at a TF-CSIRT seminar in 2010.  If a home organisation fails to deal with a problem their breach of the policy can be reported to the eduroam operator; if the misuse is an immediate serious threat to the visited organisation they are able to temporarily suspend access by all visitors from that home organisation.

The same bargain, where a home organisation agrees to deal with individual problems with the possibility of a general suspension if they fail to do so and pose a risk to others, is also used by the Janet Security Policy. Under clause 9 connected sites agree to deal effectively with reported policy breaches, and the policy allows network operator to restrict or suspend service if they fail to do so.

Some identity federations already have agreements that cover incident response, for example the UK Access Management Federation Rules of Membership require that members "must give reasonable assistance to any other Member investigating misuse" (clause 3.5) and the Recommendations on Use of Personal Data suggest that problems should be reported to, and dealt with by, the user’s home organisation (section 4). Where a federation agreement doesn’t contain similar provisions it may be possible for service providers to seek assurances from either the federation operator or individual identity providers. This should permit the service provider to request less personal data as a matter of routine, thus complying with data protection law’s minimisation principle, reducing the compliance risk to both service provider and identity provider, and perhaps making the identity provider more willing to release the information that is needed for routine access to the service. Agreeing effective incident response measures to permit reduced routine data transfer seems like a win for all: service providers, identity providers and users.

Given the benefits of agreeing a different process and information flow for handling policy breaches, it may be worth considering whether there are other exceptional circumstances that could be treated in the same way. One situation that was mentioned is where a virtual organisation needs to check which user(s) have incurred costs or used quota with a service provider. Here there needs to be an exchange of information between the service provider and the VO (and possibly the IdPs as well): agreeing the exception process in advance may both give more confidence that it will work, and allow a reduction in routine information transfers.