InCommon Library Services

["Paul B. Hill" <>]

Hi,

I agree the proposal requires a certificate per institution, not per 
user. However, some of the language implies that the certificate will be 
issued by a commercial CA, other portions imply that is not a 
requirement. I interpreted one clause to mean that if a commercial CA is 
used, T-R will not use the CA's revocation server, instead they will 
require the institution to report revocation directly to T-R via some 
unspecified non-standard process.

I suppose that if you make your pool of SubIDs have a one-to-one 
correspondence with each user at your institution, then the proposal is 
not particularly onerous. You would simply have a unique SubID as a 
directory attribute for each user. The it would be just another 
attribute for your IdP to pass in the SAML assertion :) Of course even 
doing that, you will have to manage the metadata outside of the context 
of the InCommon Federation or other federations in use in other parts of 
the world.

Paul

On 1/21/2011 2:10 PM, Kent Percival wrote:
> 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>