InCommon Library Services

[Rich Wenger <>]

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>