*Attendees*
Paul Jolly, AAMC
Jere Retzer, OHSU
June Moody, AAMC
Mary Kratz, Internet2
Renee Frost, Internet2
Bill Gordon, U. Cincinnati
Jack Buchanan, U. Memphis
Morgan Passiment, AAMC
Michael Gettes, Georgetown
Steve Olshansky, Internet2
Jeanette Fielden, Internet2

*Discussions*
The Shibboleth pilot with the University of Cincinnati/AAMC GIR project of remotely hosted web courses for online compliance training is going to happen and a call is planned for next week. The initial courses are for OSHA compliance training on blood borne pathogens, but there is potential to extend it to many other areas, such as HIPAA compliance. The course model is a core of generic training modules with institution specific modules added on. People self register at the site, provide their institutional affiliation and user name at the institution. The pilot is currently set up to track only affiliates with one of the ten AAMC institutions in the pilot. The project can provide to the institution: a list of all affiliated people that have registered, training completion status, date completed, and expiration date of the training. The ability to track other institutions is already present and the OSHA compliance component will be opened up to all AAMC member institutions for evaluation. The planned HIPAA component is more of a local effort at present. It is based on the same model of common core HIPAA training with customized institution specific training components added on. Information on any associated costs is not yet known but there are substantial cost savings expected from everyone using the same common core. The University of Texas – Health Science Center has expressed interest in the project as it progresses.

The group discussed their understanding of the requirements for audit trails and collection of information with respect to electronic medical records for creating a historical snapshot of a medical record, i.e. looking at a record at a particular time of access by a particular individual. Looking at a time snapshot of the record itself only requires dropping anything added after that time. Tracking of who was authorized at any given time might be a log of authorizations and de-authorizations. Part of the question also ties back into electronic health record systems. Sometimes they are freestanding and sometimes they are a collection of applications with different authorization schema underlying them. So it can be considerably difficult and messy to get a total snapshot.

In terms of providing the access is it too simple to view it in terms of a portal? You come to a portal and at the backend you're accessing a collection of systems. The front end should be recording access, since it's an application level issue. At the resource manager side of things in Shibboleth there may be some basic high level stuff that says "if you don't have this attribute you can't even access the web site", but it's the application that would determine what information you were authorized to see. The question of access control ties back to the meaning of roles and jobs in the medical environment. Depending on how the requirements are interpreted and roles are implemented this can become a bigger issue across the medical industry as HIPAA is implemented. [AI] Mary will check for URL's to papers/conference proceedings she referred to and forward them to the list.

A distinction was made between the authorization a front-end entry system provides and the attribute information Shibboleth provides. Shibboleth is a mechanism to gain information attributes about a person who has authenticated, so the application can make a decision about granting access to a resource. View Shibboleth as a resource to gain information about the person. The rest is an application issue. Should the application post information from Shibboleth that it used to make the decision to file? Yes, it really is a good security practice to do so.

Shibboleth clearly defines a relationship between an origin and a target but it is not between a front end and back end system. The origin at this point is fairly well defined as consisting of a set of components, usually along the lines of a handle service, web login service, and an attribute authority. The target is some kind of a target web service with a Shire, and a SHAR resource manager. That doesn't mean the origin is the front-end system and the target is a back-end system, such as a lab system. That relationship between the front-end system and the lab system is more like a portal environment. Even Shibboleth is having difficulty with architectures to address portals. It might be reasonable to take a first cut and say that the front-end system is the resource. But the front-end system access without the back-end is an application issue. It is important to note that it always comes back to an application issue. Only the application will know, when it gets information, what a person is allowed to do. It's the applications job to log it, and make those final access decisions.

If the front-end system is acting as a proxy, i.e. all accesses to other systems are by the front-end system; then the front-end system has to maintain the access lock. It's not the cleanest design but the most expedient. A better design would be to proxy through the fact that user Bob authenticated via the front-end system and the lab system decides if Bob gets access. In the first example the lab system has to trust the front-end system to have all the rules to properly process if Bob is allowed access to the lab system.

What about in an emergency situation or when the front-end system fails? The problem and rules for handling it need to be defined, and exceptions can always be found. Limits have to be defined as well. What's defined needs to be implementable, and testable to determine its viability. It's likely that the current state of practice is front-end systems that basically have system level passwords to the back end systems and aren't doing any level of granular control. It's also critical to understand which issues are technical and which are non-technical. A good future step might be to model a good relationship between the portal and the other systems. Then prioritize what can be done quickly to get something up and working in order to get feedback.

The question: "Is there a common access control language that front-end and access system will understand?" The answer is no. If it's going to be an environment where you have to go through the front-end system to get to the lab system and the front-end system does all the authorization checks then that is the system you're designing and you need to engineer it such that the front never goes down, i.e. how are failovers handled.

[AI] Bill will start talking to people at Cincinnati about possibly expanding the project to include Shibboleth and some simple attributes such as faculty, student.

The next call will be Thursday January 23, 2003.