InCommon Library Services

["Kent Percival" <>]

YUCK!!!!     I’m checking with our Library and with the libraries Scholars Portal service that aggregates service provider content for all Ontario university libraries.

 

The proposal is badly written and parts can be interpreted in several ways.  E.g. I interpret the certificate function differently than Paul … It looks like one certificate per institution (i.e. one per client institution not user), for signing transactions, just like SAML. 

 

TR is trying to manage pooled login “subID”s in a complicated way requiring essentially a TR IdP to dish out the subIDs.  A complicate overhead for little vale for the customer site.  In fact subIDs are reset for each session, eliminating the great value of persistent sessions where a user can come back to where they left off last time.

 

I certainly think it deserves a response.  Anything that requires substantial configuration and programming on the customer side is not a good solution from a major provider.

 

 

....Kent

 _

 

From: [mailto:] On Behalf Of Rich Wenger
Sent: January 21, 2011 11:40
To:
Cc:
Subject: [inc-librsvcs] an appalling pitch from Thomson Reuters

 

One of our vendors of e-content, Thomson Reuters, tried to convince us to implement a really bad new connection/authentication infrastructure.  Please see the attached document for the grim details.  I’m wondering whether other institutions have been approached in this way.  Can we generate a joint response to this?

 

This proposal is so onerous that it is hard to summarize, but the following comments from Paul Hill are a good attempt.

 

Rich Wenger
E-Resource Systems Manager, MIT Libraries

617-253-0035 

 

<Paul’s comments>

Some quick reasons on why I have a negative first impression of the Thomson Reuters document:

 

- Although the document says it "provides support for single sign-on federation standards", it doesn't use a federation. Instead it requires each customer to "exchange of X.509 certificates between the client and Thomson Reuters." [Note: In this case, the client appears to mean a campus portal server.] [Note: The document does not discuss what type of

X.509 certificates are acceptable. E.g. self-signed, issued by a campus CA, requiring certificates from a commercial CA, or perhaps the certificates must be issued by a CA operated by Thomson Reuters".

 

- The proposal attempts to create a system which heavily relies on a PKI, and yet dictates that the "infrastructure" portion of a PKI will not be used. For example, "revocation is managed through business-to-business process rather than through the 3rd party certification authority."

 

- The document says, "Although a strict adherence to the SAML protocol requires an Identity Provider intermediary to map identifiers, for simplicity this is avoided. Instead the client authentication system is responsible for mapping to the Seed SubId the user belongs to." In other words, the proposed system does not require that a campus IdP be used for authentication. Instead it 'allows' for the customer's portal server to perform the authentication and the customer's portal server is expected to create the SAML token.

 

- The diagram in section 4.2 implies this is not a SAML federation. The proposal is to create a Thomson Reuters federation which requires that customers become members of the federation.

 

- The proposal creates undue burdens on the customer "administrator".

SubIDs are only 6 characters long, they do not contain am expiration indicator. Customers sites will have a limited number of valid SubIDs to associate with users. Users do not necessarily log out of browser, they can simply close a browser at any time. In such cases the cusomter's portal server cannot determine that the SUbID should be released back into the pool and be re-issued to another user. Instead the customer's "admin user" will have to manually perform this task.

 

If MIT were to implement a system which supports this proposal, it appears that a new attribute resolver would have to be written for the MIT IdP. Furthermore, a web application would have to be written which would manage the SubID issuance, and someone would have be given the privileges to release SubIDs back into the pool, when users simply close their browsers instead of logging out.

 

In summary the proposal places undue burden on the customer site, is not standards compliant, does not scale well, and is ill conceived.

 

Paul

</Paul’s comments>

 

 

 

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