Ticket/HTTP Stream in Jargon

[Conway, Mike]

Hi all,

I was happy to see many of you in Tucson, it was a great meeting.  There will be a stream of things announced on IRODSChat that were alluded to during presentations, and this is the first.

In a collaboration between RENCI, DICE, and iPlant, iRODS is developing a ticket feature, as described here: https://www.irods.org/index.php/Ticket-based_Access

As Wayne described the features:

Features

Users will be able to create tickets and associate them (one to one) with a data-object (iRODS file) or collection (directory). These will be either system-generated pseudo-random strings, 16 characters long, composed of upper and lower case characters 'A' through 'Z' and 0 thru 9; or optionally specified by the user creating the ticket.

Tickets are plain-text strings, not encrypted.

Only users with 'own' permission on objects will be allowed to create tickets for those objects (and modify or delete them). When the ticket is used, this will be rechecked and access denied if the original user no longer has 'own' permission.

Each ticket will be associated with one data-object or collection, although multiple tickets can be defined that refer to the same object.

Users will be able to access objects using tickets even if they do not have regular access permissions (the regular access is set via 'ichmod' or equivalent, giving users or groups read, write, or own permission). In the case of tickets on collections, all data-objects under that collection (including those in sub-collections) will be accessible (readable) via that ticket.

Users can either be normally logged into iRODS (as a regular, specific user) or not (connected as user 'anonymous', with no password).

Tickets can be set to last indefinitely or to expire at a certain time.

Tickets can be set to be usable any number of times, or to only be valid for a specified number of uses.

Tickets can be associated with specific users or groups, in which case access will be granted only if the valid ticket is presented from those users or users in those groups.

Tickets can be set to be valid only from specific computers (DNS host names), in which case ticket-based access will be denied when iRODS clients are connecting from other hosts.

When iRODS auditing is enabled, ticket-based accesses will be logged in the audit table.

It is expected that 'read' access will be the main ticket-access mode but 'write' tickets will be implemented too. Users will be able to grant ticket-based write access to a collection, with that access limited in both total number of files and bytes stored (since ticket based access is less secure, the mode needs to be limited). The iRODS system will track the file count and total storage space used via each 'write' ticket and enforce a quota limit (i.e abort another 'iput' if the limit has already been reached).

This message is to announce that the jargon-ticket package has been added to jargon-core, in the 3.0.0.2-SNAPSHOT and master on git.  There is a service class for administrative operations (create, query, manage tickets) and a client class (redeem tickets for put/get operations).  If you check out jargon-core from git, you can see the new libraries.  These are also available on maven.

We also have a new jargon-httpstream as a separate service package to stream HTTP content into iRODS.  This subproject utilizes Apache HTTPClient, so it can grow to do more sophisticated HTTP operations (redirects, different auth models).

Status

We are inviting early adopters of tickets to start reviewing/commenting on the API and to begin testing.  This should be treated as alpha, and we would appreciate community contributions of bug reports/feature requests/testing in various scenarios.  Use the Jargon Gforge project, we've added jargon-ticket to the tracker components

• Ticket API is significantly implemented in jargon
• Unit tests are passing
• TODO:
  • More unit tests for edge cases
  • More API updates
    • Creating a ticket on a collection with write does not automatically set inheritance on the collection, we may add signatures to do the inheritance flag setting during ticket create
    • Other method signatures
    • Continued unit/functional testing
    • Various services for extended ticket modes
      • 'mail' a ticket?
      • Ticket support in iDrop suite

Note that tickets requires running the trunk code of iRODS, this is currently planned to be in the next release.  Your testing and community contributions will certainly help!

Mike C

---------------------

Mike Conway

Java Architect – DICE

www.irods.org

skype:michael.c.conway

LinkedIn: http://www.linkedin.com/pub/mike-conway/5/78a/231