[WG-UMA] Audit in UMA

Zhanna Tsitkov tsitkova at mit.edu
Wed Aug 27 19:06:18 CDT 2014


Hello,
I have updated the audit spec candidate per our discussion at the last UMA-WG meeting. Please, see https://docs.google.com/document/d/1h8Hq6bJVW3_l7DE4U45uipIKsFBYWf6sf8HfH0UjHwI .
As you can see, the Motivation section need some real life examples.
Your input, ideas, advices on use-cases and the topic in general are very much appreciated.

Also, on another note, is it possible to have a wiki page hosted by UMA/Kantara for this draft?

Thanks,
Zhanna

On Aug 18, 2014, at 4:12 PM, Zhanna Tsitkov <tsitkova at MIT.EDU<mailto:tsitkova at MIT.EDU>> wrote:

Hello,
I would like to share with you a (very-rought) draft Audit in UMA,  Please, see the text  below.  What do you think about it?  Also, I was not sure what is the best/preferred  format to present it to the WG, so I hope it is OK that I  just put it in the text of the email.
Thanks,
Zhanna

Audit in UMA

Introduction

This specification is an effort to provide guidelines for implementing the Audit functionality for UMA enabled environments.

The data of interest for the UMA audit includes permissions, scopes, claims, policies, and other authorization and authentication related information.  It can be used by government agencies and various institutions for fast violation response, credential revocation, forensic analysis, etc.

This document introduces an audit ID (audit_id) – an identifier with the following properties:
1.     It is unique for a given UMA exchange;
2.     It stays unchanged at any stage of the UMA exchange;
3.     It is generated as part of UMA processing, or is obtained from the upstream RS’s;
4.     It is protected against data tampering;
5.     It is available to all participants of the UMA exchange to be recorded for their audit needs;
6.     It can be passed to downstream RS’s.


Section 1. Audit ID

The audit identifier can be an (random) alphanumeric string, or a JSON structure.

The uniqueness of the audit id is important especially in the cases when audit logs are processed dynamically.  Since randomizers on Clients are commonly weaker and less collision-resistant when compared to AS randomizers, in most environments, it should be the responsibility of AS to generate a high quality “strong” audit id.  However, it should be allowed for the Client to have its own audit id’s for the internal book-keeping.  This identifier can be passed to the authorization server as part of the initial request and AS should include it in the reply messages together with the “strong” AS-selected audit id.

AS may adopt any audit identifier coming from the Client as a “strong” audit ID if it believes that it is a high quality identifier.

Section 2. Flow

The following are the possible scenarios of obtaining the audit_id:

1.     AS-generated audit ID

Upon successful authorization, AS generates audit_id and includes it in all further communications. For example:

HTTP/1.1 201 Created ….
{….
            “audit_id”: “xyz”,
};

2.     AS receives audit ID from the Client.

Client sends a client audit id (cl_audit_id) directly to the AS:

POST … { “cl_audit_id” : “abc”, …}

AS generates its own audit id and sends it back, along with other information to the client:

HTTP/1.1 201 Created ….
{
            ….
            “audit_id”: “xyz”,
            “cl_audit_id” : “abc”,…
}

Alternatively, AS may derive audit_id from the cl_audit_id following some agreed upon rules.  For example, audit_id = cl_audit_id . current_time:

HTTP/1.1 201 Created ….
{
            ….
            “audit_id”: “abc.123”,
}


Section 3. Audit log parameters

It is considered a good practice to keep the audit log concise. Overloading logs with unnecessary information comes with the burden of extra storage allocation and protection, and less effective information processing (both time-wise and resource-wise).

The following are the recommended parameters that, when applicable, should be included in the UMA audit logs both for AS and RS. All security sensitive information should be stripped and not logged.

audit_id  - A non-modifiable identifier that is used to track all participants on all stages of the UMA exchange;

event_type  - A type of event. For example,  “permissions problem;”

event_category  - Type of action performed when audit is generated. For example, RS processing;

timestamp  - A timestamp when event was logged;

event_outcome - Indicates whether the event is reported on success or failure;

endpoint_uri - Registration, token, etc URI.
Alternatively, use Authorization headers or POST parameters instead of URI request parameters; (http://tools.ietf.org/html/rfc6819#section-4.6.7);

source   - Code specifying the type of source where event originated;

permissions - Requested, granted (,“hoping for”?) permissions including resource id, lifetime, scopes, and other security insensitive access attributes;

permission_ticket  - Details of the permission ticket;

token_status - Full token status, including validity periods, corresponding refresh tokens, etc.

access_policies - Resource owner access policies;

Claims - Identity claims;

Agreed_to_obligations   - per Binding Obligations draft.

The audit implementers have the opportunity to customize audit logs by extending auditable parameters and events, and making audit logging configurable.


Section 4. Event selection

In general, all AS-RS , Client-RS, Client-AS interactions, successful or not, should be recorded in the audit log files. This includes:
- Permission requests;
- Token issuance;
- Resource Set registration;
- Token introspection.

Section 5. Audit vs privacy

In some cases it becomes desirable to protect the real identity of the user from the exposure in the audit logs.  It can be governed by policy settings on AS or RS.  The user identities can be completely omitted from the logs and some pseudonyms can be used in lieu of real names.  In this case the AS or RS, respectively, should support some table that matches the RO or RP to their pseudonyms.

Section 6. Audit log protection.

 TBD

-       audit_id is signed by AS;
-       Unauthorized access to log files:
o   Overstepping privileged user authority;
o   Client should not have right to look at server’s logs.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-uma/attachments/20140828/384ce3fc/attachment-0001.html>


More information about the WG-UMA mailing list