InC-Lib-Vendor

["Kent Percival" <>]

David, et al.

I really appreciated the presentation and discussion of Michigan’s multi-campus use case at the tele-meeting on Friday.  It presents an important problem for the “federated access” community to tackle both on a pragmatic and strategic level.

At the pragmatic level, as I noted on the call, the process of finding a small community that is willing to tackle the problem, propose a solution, and demonstrate it with a live implementation is the way many things have moved forward in the development of the internet.   The success of one or more implementations leads to best practice and eventually community “standards”.

>> I support the strategy of building a community of interest to determine “what next”.  We need to encourage that group to focus in on a solution and implementation.  Getting support from a few vendors is crucial.

 

On the other hand, the scope of this problem is potentially far-reaching.  Other jurisdictions, such as UK JISC, may also be considering solutions.  Applications from service providers beyond the narrow scope of the core library resource providers will have similar issues.  An example to ponder is iTunes – as I understand some universities are working with Apple to define the attributes and entitlements that would be exchanged for that specific application (see InCommon Participants list).  Some libraries may consider iTunes a potential service provider.   This broad scope requires a parallel investigation to determine whether other groups are also working on the problem, whether other solutions already exist, and whether a more comprehensive solution is possible.

The MACE-paccman Working Group (Privilege and Access Management) is working at the more conceptual level to understand how authorization (or access management) policy is defined and implemented in the federated space.  One of the big challenges they started with is the vocabulary – each application community has used different terms and definitions).   The big question though is where should access management policy be implemented.  At the highest level, should the Provider be responsible for policies controlling access to their service, or should the customer agent (university) be responsible for determining that by establishing entitlement.  At the practical level, should the SP have a policy engine that interprets authorization data from the customer, or should the IdP make the determination based on protected, private, information not shred with the provider?  In reality there are use cases for all angles!  … One of the interesting use cases arises in the research community, as well as some commercial use cases, where access control may be determined on the basis of information provided by more than one IdP.  The SP must then apply local policies to that information.

The bottom line is that access management policy needs a more comprehensive architecture and protocol definition. As well the challenge is not just entitlement assertion but also provisioning of group/role/permission information in the identity management system.  Products like Grouper and perMIT are leading the way.

>> Perhaps Steve Carmody could talk to us about how some the other IAM & federation developments could impact the challenge of the Michigan use case.  Does he know of other Internat2/InCommon/Shibboleth teams that would be interested in solutions to this use case?

A lot of the best practice related to federation for library services came out of JISC in the UK.  JISC was focused on library services and wanted to improve upon the access management they achieved with their Athens system.  The SAML standard, supported by the Shibboleth implementation became that direction and the vendors already engaged with the old system helped define the transition.  Early on the goal was speed of implementation and the vendors resisted building complex policy management agents onto the SP.  Through JISC most supplier agreements were broad based, arranged by JISC.  A simple entitlement assertion was all that was needed and the institutions agreed to implement the policy agent that determined the entitlement.  That was “Phase 1” – now more complex use cases demand more attention to how the access policy functions are implemented and what “standards” are needed to facilitate that policy implementation.

>> The challenge is not just an InCommon Library group one.  To engage large proactive vendors who are driven by the scale of the issue across their customer base, we need to demonstrate that the intent is not to invent local proprietary solutions but ones that would be adopted across their international customer community.  We also need to convince them that they are part of that international collaboration and they can provide leadership by helping to develop the initial live demonstrations.

 

....Kent

 _

 

Attachment: smime.p7s
Description: S/MIME cryptographic signature