Date: Tue, 19 Mar 2024 01:07:11 +0000 (UTC) Message-ID: <2006196065.3389.1710810431914@fra-prod-wiki02.geant.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_3388_569250530.1710810431912" ------=_Part_3388_569250530.1710810431912 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Federation operators and eduGAIN experts are frequently asked ho= w to test access to a production federated service. A simple login test to = a federated service requires a federated account at an organisation that is= part of the federation/eduGAIN. However, commercial service operators norm= ally don't have federated accounts in a national federation and eduGAIN. An= d even if they had a single account of their own or if they asked a real-wo= rld user to test, this would not be sufficient to thouroughly test federate= d login with multiple identities and different sets of attributes.
Setting up a SAML Identity Provider (IdP) and using it to test its Servi= ce Provider (SP) would be ideal but is non-trivial and therefore in most ca= ses too much effort. Using self-registration IdPs and configuring them bila= terally with their Service Provider (SP) might be sufficient for developmen= t but as these IdPs are not part of eduGAIN, they don't allow federated log= in under real conditions from an eduGAIN IdP. Also, self-registration IdPs = usually don't allow certain attributes (e.g. affiliation) to be set.
The eduGAIN Access Check solves most of the forementioned issues because= it provides SP operators an easy way to test federated login for their edu= GAIN service with test identities that have different attribute profiles.= p>
The eduGAIN Access Check allows SP administrators to ensure proper funct= ioning of their services within eduGAIN. It is especially useful for servic= es not hosted by an R&E institution, because they can't use their own I= dP to login and test their production eduGAIN-enabled service. Setting up a= n IdP on their own would require considerable efforts on their part.
The eduGAIN Access Check provides realistic user profiles (e.g. includin= g non-ascii characters, typical attributes) to help SP administrators to im= prove and adapt their eduGAIN-enabled services to the constraints of variab= le attribute release in an international context. In particular, the eduGAI= N Access Check makes the SP operators aware that:
SAML2 entity categories (G=C3=A9ANT Data Protection Code of Conduct, REF= EDS Research & Scholarship) support for attribute release management is= a non-trivial concept within eduGAIN. The eduGAIN Access Check releases a = reasonable set of attributes to SPs, depending on the entity categories the= y belong to. This should encourage SP administrators to follow the eduGAIN = guidelines and facilitate the use of entity categories.
Your Service Provider first needs to be registered in eduGAIN metadata. = Therefore, you should contact your nearest federation operators (please hav= e a look at the list of eduGAIN member federations) to f= ind out about the local process to join eduGAIN.
Once your SP's metadata is included into eduGAIN, you can st= art creating test accounts. Before you obtain the test accounts, it is = checked that you are a legitimate administrator of your SP. This is achieve= d via an email challenge sent to the contact address for the Service Provid= er.
To use the test accounts, initiate a login at your SP. On the Discovery = Service, select "eduGAIN Access Check" as your Identity Provider and then u= se the credentials of one of the created test accounts. Once authenticated,= the eduGAIN Access Check IdP will release a set of attributes with realist= ic values, based on those associated with the account, and those explicitel= y requested by the SP, according to its metadata. This allows you to valida= te that your service behaves as expected.
Test accounts expire automatically after a few days. However you can ask= for new test accounts, via the same process, if you still need it.
The code of the eduGAIN Access Check Account manager is published as ope= n source. It's available at: FIXME. Feel free to install it to run you own = instance of the service.
If national federations don't want to have their own service but still w= ant the eduGAIN Access Check as a service in their federation to be use by = all their SPs, they can request that. The eduGAIN Access Check then would b= e configured to also load the metadata of that federation in addition to ed= uGAIN. Vice versa, the national federation then would have to include the metadata of the eduGAIN Access = Check IdP in their local federation's metadata.
Test identity providers provide test accounts, with well-known accounts = credentials. If such a test IdP is registered in eduGAIN, it allows access = to any registered eduGAIN SP with these test accounts, unless the test IdP = is filtered out, either at the SP level or at national federation level.
Guest or self-registration identity providers typically allow all users = with a valid email address to create an account and access federated servic= es with it. This is mainly for users who don't/can't have an account at an = institutional IdP. These guest IdP rely on mail address verification (based= on a challenge for instance) as a provisioning method but any other attrib= ute is either self-provided by the user (unknown quality) or static. Theref= ore, tis type of IdP provides generally provides low quality attributes abo= ut the users (name, email, user identifier) and typically cannot release us= er attributes carrying privileges because data is self-provided by the user= . Guest or self-registration Identity Provider therefore are generally not = recommended to be part of eduGAIN.
Unlike a test IdP, eduGAIN Access Check test accounts credentials are pr=
ovided to the requestor only.
Unlike a guest or self-registration IdP, the eduGAIN Access Check test acco=
unts creation is a restricted feature; you need to proove that you are admi=
nistrator of an eduGAIN production SP to use it.
Unlike for a standard IdP, the eduGAIN Access Check test accounts can be us=
ed to access a single SP. If you request test accounts as admin of SP A; th=
ese test accounts won't allow accessing any other SP than A.
The eduGAIN Access Check service exclusively allows creating test accoun= ts for users who can receive challenge emails for contact email addresses l= isted in the eduGAIN metadata for a particular Service Provider. The test a= ccounts can be used exclusively to access a single SP (for which a user pro= ofed that he is administrator for). Authentication requests for other SPs a= re rejected.
The attributes that are typically needed for user identification have a = hard-coded domain name ("@access-check.edugain.org") set. The= refore, they cannot be changed unless the host is hacked, which could happe= n of course to any Identity Provider. The eduGAIN Access Check also has the= Shibboleth metadata scope extension set to "access-check.edugain= .org" in its published metadata. Therefore, an SP with enabled scope ch= eck would not accept for example an eduPersonPrincipalName with a different= scope.