GakuNin VO Platform – GakuNin mAP - Takeshi NISHIMURA (GakuNin, NII, Japan) TERENA VAMP workshop, Utrecht 2012.09.07
is an academic access federation in Japan, since 2010. *1 Current status: # of IdPs – 42, # of IDs ~ 50k # of SPs - 89 Continuously extending federation functionality e.g. uApprove.jp, GakuNinDS, … *1 – https://www.gakunin.jp/en/
Our VO Platform: GakuNin mAP (mAP = member Attribute Provider) Provides membership information of groups to services within our federation. It is only one entity in the federation. Each university does not have own entity of mAP. (Though it is not forcible, just recommended) All groups are stored in this entity. It accepts any request of all SPs in the federation. various SPs, including unknown/unfamiliar SPs Currently it has no connector for external LDAP etc.
For example, E-book services which have contracts with small groups Mailing list provider for various groups File sharing service for communities and any other services utilizing the concept of “group of IDs” including lightweight collaboration
e.g. laboratories in universities, inter-university research groups, … Used by various SPs (groupware, e-Journal, …) each SP has a different aim collaboration works are usually so complicated ― i.e. only 1 SP will not suffice
Traditional federation contains only IdPs and SPs Access control is basically based on the attributes from an IdP source of ID group information IdP-led groups constructible by the information which IdP has SP-led groups constructible by the information which SP has theoretically possible but with much cost Third-party led groups constructible by the information which another entity has
Predefined IdP attributes are coarse-grained. e.g. eduPersonAffiliation and organizationalUnitName IdP administrators cannot handle all of them in ID management system. e.g. members of a laboratory, a joint research project, ... → There should exist another entity to handle them in the federation. – Attribute Provider (AP)
Goal of our VO platform: Widely-used & user-friendly VO platform Lightweight integration 1. Controlled user consent 2.
SimpleAggregation (Shibboleth SP built-in) back-channel communication just after authn. by IdP just adding a few lines into SP’s configuration file People API / Group API (optional) for e.g. mailing list service
Which user ID do we use? ePPN (eduPersonPrincipalName) Which group ID do we use? specific URI e.g. “gakuninhelp” group in GakuNin mAP = https://map.gakunin.nii.ac.jp/gr/gakuninhelp administrators of “gakuninhelp” group (is virtually a group) = https://map.gakunin.nii.ac.jp/gr/gakuninhelp/admin
VOOT-like simple protocol to retrieve member / group information* 2 People API https://map.gakunin.nii.ac.jp/api/people/@me/GROUPID[?lang= NN] Group API https://map.gakunin.nii.ac.jp/api/groups/@me?[lang= NN] But using TLS client certificate authentication SP’s certificate in metadata Even openssl command can be used to retrieve information. *2 - https://meatwiki.nii.ac.jp/confluence/x/lwic (in Japanese)
On the assumption that many SPs exist, To avoid unintentional information disclosure and to prevent malicious SP’s information retrieval Much information confuses user. The flow of the membership information should be under the control of group administrators Then users do consent for limited number of SPs on mAP in advance. avoids back-channel consent issue by SP Connector
provides membership information of groups to services within an identity federation services SP SP Q P isMemberOf: SP operator SID-P, GID-2 SP Connector Q GakuNin mAP SP Connector P Group admin Group Group Group 2 1 3 Univ. A Univ. B Access Univ. C to SP P IdP IdP IdP B A C User X
SP Connector is a representation of SP in GakuNin mAP, controlled by SP administrator. To avoid privacy issues GakuNin mAP sends minimum information of groups which have connections with the SP Connector. The connection is built when Group admin and SP admin agree. Then each member does the consent.
SP SP SP • Retrieve Member attribute membership info requester like IdP Member attribute authority GakuNin mAP • Store group membership info Group • Create group management UI • Add/remove members • Visualize group connections like SP Users
“meatwiki” from NII 1. General Wiki service to share information in an arbitrary group “shibosuke” from a private company 2. Scheduling service among arbitrary group members “youzan” from Yamagata University 3. Communications service for sharing academic information “meatmail” from NII 4. Mailing list service “ARCADE” from Kanazawa University 5. File sharing with group permission
IdPs in Japan do not want to release ePPN to each SP. (due to privacy) Contract-base SPs does not need ePPN. Read access on Wiki does not need ePPN. Front Channel Aggregation* instead of SimpleAggregation * needs Shibboleth SP modification
Inserts second authentication request just after normal authentication. Each SP needs no NameID. mAP(SP) SP mAP(IdP) University IdP authn. request (normal flow) authn. response (normal flow) second authn. request second authn. request from mAP IdP’s entityID ePPN (for mAP) isMemberOf retrieve group info.
Thank you for your attention
Recommend
More recommend
