Usinc Comanage to create virtual organizations
Judith Bush
•Collaboration: Many commercial SPs only support single SAML endpoints
•Domestication: groups already included
•Maintainance: VO can manage the IdPs, SPs only needs 1 vIdP configured
•Combine several IdPs into one virtual entity
•Use groups to bind users to vIdP
•Optimized WAYF
•Bind specific VO attributes
•VO != vIdP
Cheers,
judith bush
Niels van Dijk
Hi Judith,
Hello all,
I work at OCLC, a global library cooperative. I'm investigating whether there are other solutions to the federation hub software we have built.
I'm going to define an "IDP" as an entity with an entity ID and a single SSO endpoint. In general, the R&E federation world seems to associate organizations with one IDPs.
Libraries, being the collaborative organizations they are, often exist as an organization (in their contracts with service providers) separately from their home institutions. For example, consider a city that is the home of a university and a medical school. The city, university, and medical school may decided to share resources and create one library. The pool of identities comes from three sources: the identity provider for the university, for the medical school, and for the city residents. The contract with the service provider is with one organization: the service provider doesn't know about the city, medical school, and the university: just the union of all three as the patron count for the library.
The service provider expects to correlate their contract for access with the library with one entity ID and one SSO endpoint.
In OpenConext that would be the entity ID and the SSO endpoint of
the proxy. If it is a mandatory requirement that such entityId and
SSO endpoint have the (domain)name of the organization reflected,
this is not possible with OpenConext at this point. However in
many cases the technical SSO endpoint is not really relevant, as
long as it works. The entityId is just a (string) identifier for
an entity, so as long as it is a URI it may hold any (unique)
value.
What we have provided in our hub implementation is a single entity ID and SSO endpoint for the provider to access and then and additional WAYF that allows the user to select from the library's identity providers.
That is just how it would work when using OpenConext as well. The
SP connects to the hub. Using OpenConext manage, one configures
the Access Controle List which IdPs are allowed to autheticate
against that SP. The list of IdPs presented to the user is
automatically filtered to contain only the IdPs which have access.
What i am hoping is that the OpenConext + CoManage system will allow a similar behavior.
One of our libraries would configure the three IDPs (university, medical school, and city) in OpenConext, use CoManage to create a virtual organization, and then OpenConext would have four distinct endpoints: university, medical school, city, and library. The library would only expose the SSO endpoint for the virtual organization to SPs.
I am a bit confused on the endpoints. The university, medical
school and city endpoints represent IdPs. One would indeed
configure these to be connected to the proxy. As such they are
connected to the SP-side of the proxy.
The library entity is an IdP by itself and is therefor represented
at the IdP endpoint of the proxy.
SP --> [PROXY]@ SP endpoint ---- University
|__Medical
|__City
When a user now selects the login button at the SP, the request is directed to the proxy. the use is presented with a WAYF or teh 3 relevant IdPs, selects one and is then redirect to the IdP to authenticate. after success, the transaction flows back to the SP. The configuration of which IdPs are allowed to connect to the SP can be done centrally in the OpenConext manage tool, or by the operator of the entities themselfs, for the SP using the SP dashboard, or by the IdP, using the IdP dashboard.
If there were another SP wanting to connect to a different library, the same setup can be used. There is no technical need to differentiate the proxy endpoint to allow for that.
If it makes sense to present a user with a double wayf, so to
select the IdP of the Libary first, then after that select the
"real" IdP, it woudl be rather trivial to represent that in the
metadata published. The metadata allows you to present whatever
you want, as long as the technical endpoints are correct. So to
present the proxy endpoint with a displayname "Library1" would be
very easy. Also the value of the entityID is arbitrary. Having
multiple Libraries represented in the metadata there would also be
trivial.
SP --> "Library1 IdP endpoint" @[PROXY]@ SP endpoint ---- University
|__Medical
|__City
Does this help?
Regards,
Niels
I suspect from conversations at TNC19 that OpenConext + CoManage does not function that way. However an old OpenConext slide suggested the same need, and i grew hopeful again!
Virtual IdPs
Why?•Collaboration: Many commercial SPs only support single SAML endpoints
•Domestication: groups already included
•Maintainance: VO can manage the IdPs, SPs only needs 1 vIdP configured
What?
•Combine several IdPs into one virtual entity
•Use groups to bind users to vIdP
•Optimized WAYF
•Bind specific VO attributes
•VO != vIdP
Cheers,
judith bush
--
OpenConext - Open For Collaboration
---
You received this message because you are subscribed to the Google Groups "OpenConext Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openconext+...@googlegroups.com.
To post to this group, send email to openc...@googlegroups.com.
Visit this group at https://groups.google.com/group/openconext.
To view this discussion on the web visit https://groups.google.com/d/msgid/openconext/27c7d05a-c007-40f9-9ae5-f87a30ad8cec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
-- Niels van Dijk Technical Product Manager Trust & Security Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5 SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands www.surfnet.nl www.openconext.org
Judith Bush
Hi Judith,
Does this help?
Regards,
Niels
Reading your answer, i agree that if the whole proxy instance is set up for "City Library", then the entity ID and the URL for the proxy support the "City Library" organization as desired.
I'm afraid i didn't make a complete hypothetical.
- Assume a hub instance that assists many libraries in rapidly integrating with SPs.
- Consider SP1, a service provider that provides access to many libraries in the hub federation as well as other higher ed customers.
- City Library is a consortia of a city library, a university library, and a medical school. They have a contract with SP1 for access for a general research product that aggregates professional journals, some general periodicals, and newspapers. Call this product 1. City has an IDP that the library manages and is for city residents and friends of the library. City Library wants to also aggregate users from City University (which has an IDP and is part of the national federation) and users from City Medical school (which has its own IDP)
- Because the City Medical School needs special medical library resources that are not shared (expense), City Medical School has a contract with SP1 for medical journals. City medical school is also a customer of the hub.
- The library hub also includes other library customers of SP1, and half of those libraries have more than one IDP . Some number of those have similar cross library contracts to the City situation.
- SP1 wants to present a WAYF of the customers it knows. The WAYF includes City Library and City Medical School (among with the usual long lists).
- City Medical School has a unique entity ID and endpoint for the SP.
- Many library customers of SP1 who are also aggregates of IDPs are hosted at this hub. Town Library aggregates IDPs of Town, Town Univeristy, and Town Medical School. Town Library and Town Medical school are also SP1 customers; Town library only licenses the Current Events product.
Currently most of the SPs in the library space have a customer ID associated with an IP address range: that is the extent of the authentication and authorization done at the SP. The libraries manage authZ and authN with proxy systems that allow multiple IDPs as well as other controls on determining access rights for individuals to resources. The SAML principle that the IDP asserts and the SP makes authZ decisions is a "flip" in the control structure (and part of the controversial nature of RA21 for librarians).
The solution i would like to give to librarians would be that they can assert an entity ID and endpoint to the SP, and the librarians can trust that only activity from users authenticated by the IDP known by that entity ID and endpoint will be billed to the library.
The solution i see with a community using OpenConext is that if the library has more than one IDP associated with the patron community they are only accessed via a WAYF that includes all the IDPs associated with the SP.
SP1 in this case has the following relationships:
- City Library's IDP is (proxy entity, proxy SSO) with access to General Research product
- Town Library's IDP is (proxy entity, proxy SSO) with access to Current Event product
- City Medical's IDP is (cityMedical@proxy entity, cityMedical@proxy SSO) with access to Medical product
- Town Medical's IDP is (townMedical@proxy entity, townMedical@proxy SSO) with access to Medical product
Obviously, this is insufficient for the institutions that are accessed via proxy. Enter eduPersonEntitlement populated with the contract identifier.
- City Library's IDP is (proxy entity, proxy SSO) with access to General Research product, contract URN1
- Town Library's IDP is (proxy entity, proxy SSO) with access to Current Event product, contract URN2
- City Medical's IDP is (cityMedical@proxy entity, cityMedical@proxy SSO) with access to Medical product, contract URN3
- Town Medical's IDP is (townMedical@proxy entity, townMedical@proxy SSO) with access to Medical product, contract URN4
If the city library resource librarian had a contract with the hub first, City Librarian could have control over the configuring the three IDPs: City, City University, and City Medical. When City Medical comes on board as a customer, access to the Medical IDP is removed from City Librarian and granted to Medical Librarian. Presumably instead of City Librarian being able to set all the SPs that have contracts with City Library on all the IDPs, the City Librarian will have to communicate to Medical Librarian that list. That is less than ideal but workable. The problem is getting both contract URNs 1 & 2 on users authenticated by the City Medical's IDP. Will CoManage allow the City Library to add an additional URN to that attribute? Also, the eduPersonEntitlement specification says that "The trust between the two parties must be established out of band. One check would be for the target resource provider to maintain a list of subscribing institutions. Assertions of entitlement from institutions not on this list would not be honored." How will SP1 link the institutions with the IDP assertions when one customer institution spans three IDPs and overlaps another customer using one of the three IDPs? Can a virtual Organization solve that?
Thanks for reading my painful hypothetical! I think i have just drafted my presentation for the TechEx Proxy panel discussion in December.
judith