Skip to content
Snippets Groups Projects
Commit a854bd6f authored by renater.salaun's avatar renater.salaun
Browse files

update of presentation

git-svn-id: https://svn.geant.net/GEANT/edugain_testidp_account_manager/trunk@97 047e039d-479c-447e-8a29-aa6bf4a09bab
parent 11050d80
No related branches found
No related tags found
No related merge requests found
...@@ -234,92 +234,104 @@ $(function() { ...@@ -234,92 +234,104 @@ $(function() {
<div class="row"> <div class="row">
<h2>What for?</h2> <h2>What for?</h2>
<p>
In their daily lives federation operators and eduGAIN experts are frequently asked, In their daily lives federation operators and eduGAIN experts are frequently asked,
how access to a production federated service can be tested. A simple login test to a federated service requires a federated account at an how access to a production federated service can be tested. A simple login test to a federated service requires a federated account at an
organisation that is part of the federation/eduGAIN. However, on one hand commercial service operators normally don't have and normally organisation that is part of the federation/eduGAIN. However, on one hand commercial service operators normally don't have and normally
don't received federated accounts in a national federation and eduGAIN. On the other hand, even if they had a single account of their don't received federated accounts in a national federation and eduGAIN. On the other hand, even if they had a single account of their
own or if they asked a real-world user to test, this would not be sufficient to thouroughly test federated login with multiple identities own or if they asked a real-world user to test, this would not be sufficient to thouroughly test federated login with multiple identities
and different sets of attributes. and different sets of attributes.
<br/><br/> </p>
<p>
Setting up an own Identity Provider and configuring it with their SP would be ideal but is non-trivial and therefore Setting up an own Identity Provider and configuring it with their SP would be ideal but is non-trivial and therefore
in most cases too much effort. Using self-registration IdPs (e.g. <a href="https://openidp.feide.no/">https://openidp.feide.no/</a>) in most cases too much effort. Using self-registration IdPs (e.g. <a href="https://openidp.feide.no/">https://openidp.feide.no/</a>)
and configuring them bilaterally with their SP might be sufficient for development but as these IdPs are not part of eduGAIN, and configuring them bilaterally with their SP might be sufficient for development but as these IdPs are not part of eduGAIN,
they don't allow federated login under real conditions from an eduGAIN IdP. Also, self-registration IdPs usually don't allow they don't allow federated login under real conditions from an eduGAIN IdP. Also, self-registration IdPs usually don't allow
certain attributes (e.g. affiliation) to be set. certain attributes (e.g. affiliation) to be set.
<br/><br/> </p><p>
The eduGAIN Access Check solves most of the above-mentioned problems because it provides SP operators an easy way to test The eduGAIN Access Check solves most of the above-mentioned problems because it provides SP operators an easy way to test
federated login on their eduGAIN service with test identities that have different attribute profiles. federated login on their eduGAIN service with test identities that have different attribute profiles.
</p>
<h2>Benefits of the eduGAIN Access Check</h2> <h2>Benefits of the eduGAIN Access Check</h2>
<p>
The eduGAIN Access Check allows SP administrators to ensure proper functioning of their services within eduGAIN. The eduGAIN Access Check allows SP administrators to ensure proper functioning of their services within eduGAIN.
It is especially useful for services not hosted by an R&E institution, because they can't use their own IdP to login It is especially useful for services not hosted by an R&E institution, because they can't use their own IdP to login
and test their production eduGAIN-enabled service. Setting up an IdP on their own would require considerable efforts on their part. and test their production eduGAIN-enabled service. Setting up an IdP on their own would require considerable efforts on their part.
<br/><br/> </p><p>
The eduGAIN Access Check provides realistic user profiles (e.g. including non-ascii characters, typical attributes) to help SP The eduGAIN Access Check provides realistic user profiles (e.g. including non-ascii characters, typical attributes) to help SP
administrators to improve and adapt their eduGAIN-enabled services to the constraints of variable attribute release in an administrators to improve and adapt their eduGAIN-enabled services to the constraints of variable attribute release in an
international context. In particular, the eduGAIN Access Check makes the SP operators aware that 1) different eduGAIN IdPs will international context. In particular, the eduGAIN Access Check makes the SP operators aware that 1) different eduGAIN IdPs will
release varying set of attributes 2) the vocabulary and semantics of some attributes (i.e. eduPersonAffiliation) differ from federation to federation. release varying set of attributes 2) the vocabulary and semantics of some attributes (i.e. eduPersonAffiliation) differ from federation to federation.
<br/><br/> </p><p>
SAML2 entity categories (GÉANT Data Protection Code of Conduct, REFEDS Research & Scholarship) support for attribute SAML2 entity categories (GÉANT Data Protection Code of Conduct, REFEDS Research & Scholarship) support for attribute
release management is a non-trivial concept within eduGAIN. The eduGAIN Access Check releases a reasonable set of attributes 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 they belong to. This should encourage SP administrators to follow the eduGAIN guidelines to SPs, depending on the entity categories they belong to. This should encourage SP administrators to follow the eduGAIN guidelines
and facilitate the use of entity categories. and facilitate the use of entity categories.
</p>
<h2>Frequently asked questions</h2> <h2>Frequently asked questions</h2>
<h3>I run a SAML-enabled service. How can I use the eduGAIN Access Check?</h3> <h3>I run a SAML-enabled service. How can I use the eduGAIN Access Check?</h3>
<p>
Your Service Provider first needs to be registered in eduGAIN metadata. Therefore you should contact your nearest federation operators (<a href="http://edugain.org/technical/status.php">check the list Your Service Provider first needs to be registered in eduGAIN metadata. Therefore you should contact your nearest federation operators (<a href="http://edugain.org/technical/status.php">check the list
of eduGAIN participating federations</a>) to find out about the local process to join eduGAIN. of eduGAIN participating federations</a>) to find out about the local process to join eduGAIN.
<br/><br/> </p><p>
Once your SP metadata get included into eduGAIN's, <a href="/accountmanager?action=account_wizard">you can start the test accounts creation process</a>. Once your SP metadata get included into eduGAIN's, <a href="/accountmanager?action=account_wizard">you can start the test accounts creation process</a>.
Before you obtain these test accounts, we'll need to ensure you are a legitimate administrator of your SP. This is achieved via an email challenge. Before you obtain these test accounts, we'll need to ensure you are a legitimate administrator of your SP. This is achieved via an email challenge.
<br/><br/> </p><p>
You can then initiate a login at your SP. You will select "eduGAIN Access Check" as your Identity Provider and use the credentials of one provided test account. You can then initiate a login at your SP. You will select "eduGAIN Access Check" as your Identity Provider and use the credentials of one provided test account.
Once authenticated, the eduGAIN Access Check IdP will send your SP realistic sets of user attributes to help you validate your service behaves as expected. Once authenticated, the eduGAIN Access Check IdP will send your SP realistic sets of user attributes to help you validate your service behaves as expected.
</p>
<h3>How long can I use the eduGAIN Access Check test accounts?</h3> <h3>How long can I use the eduGAIN Access Check test accounts?</h3>
<p>
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. 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.
</p>
<h3>How can I provide the eduGAIN Access Check within my federation?</h3> <h3>How can I provide the eduGAIN Access Check within my federation?</h3>
<p>
The code of the eduGAIN Access Check Account manager is published as open source. It's available at: The code of the eduGAIN Access Check Account manager is published as open source. It's available at:
<a href="svn+ssh://svn@svn.geant.net/GEANT/edugain_testidp_account_manager">svn+ssh://svn@svn.geant.net/GEANT/edugain_testidp_account_manager</a>. You can install it to <a href="svn+ssh://svn@svn.geant.net/GEANT/edugain_testidp_account_manager">svn+ssh://svn@svn.geant.net/GEANT/edugain_testidp_account_manager</a>. You can install it to
run you own instance of the service. run you own instance of the service.
<br/><br/> </p><p>
If national federations don't want to have their own service but still have the test idp in their federation for anybody, If national federations don't want to have their own service but still have the test idp in their federation for anybody,
they could ask and request for that, in which case the eduGAIN Access Check then would also load the federation metadata they could ask and request for that, in which case the eduGAIN Access Check then would also load the federation metadata
of that federation in addition to eduGAIN. The national federation then would have to add the eduGAIN Access Check IdP on their own to their local federation. of that federation in addition to eduGAIN. The national federation then would have to add the eduGAIN Access Check IdP on their own to their local federation.
</p>
<h3>How does this identity provider compare with test identity providers and guest identity providers?</h3> <h3>How does this identity provider compare with test identity providers and guest identity providers?</h3>
<p>
Test identity providers provide test accounts, with well-known accounts credentials. If such a test IdP is registered 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 SP, through these test accounts, unless the test IdP is white-listed, in eduGAIN, it allows access to any registered SP, through these test accounts, unless the test IdP is white-listed,
either at the SP level or at national federation level. either at the SP level or at national federation level.
<br/><br/> </p><p>
Guest identity providers provide user account to users who don't/can't have an account at an institutional IdP. Guest identity providers provide user account to 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. These guest IdP rely on mail address verification (based on a challenge for instance) as a provisioning method.
This type of IdP provides a poor user profile (name, email, user identifier) and cannot release user attributes carrying privileges. This type of IdP provides a poor user profile (name, email, user identifier) and cannot release user attributes carrying privileges.
It is not recommended to register these IdPs in eduGAIN. It is not recommended to register these IdPs in eduGAIN.
<br/><br/> </p>
<p>
Unlike a test IdP, eduGAIN Access Check test accounts credentials are provided to the requestor only.<br/> Unlike a test IdP, eduGAIN Access Check test accounts credentials are provided to the requestor only.<br/>
Unlike a guest IdP, duGAIN Access Check test accounts creation is a restricted feature; you need to proove you are admin of an eduGAIN production SP to use it.<br/> Unlike a guest IdP, duGAIN Access Check test accounts creation is a restricted feature; you need to proove you are admin of an eduGAIN production SP to use it.<br/>
Unlike a standard IdP, duGAIN Access Check test accounts can be used to access a single SP. If you request test accounts Unlike a standard IdP, duGAIN Access Check test accounts can be used to access a single SP. If you request test accounts
as admin of SP A; these test accounts won't allow login if the client SP is not SP A. as admin of SP A; these test accounts won't allow login if the client SP is not SP A.
</p>
<h3>How is it ensured that users can only test their own service?</h3>
<p>eduGAIN Access Check exclusively allows creating test
accounts only to users who can receive challenge emails for email
addresses listed in the eduGAIN metadata for a particular Service Provider.
The test accounts can be used exclusively to access a single SP (for which a user proofed that he is administrator).
Authentication requests for other SPs are rejected.
</p>
<h3>What prevents this identity provider to be used to impersonate real eduGAIN users?</h3> <h3>What prevents this eduGAIN Access Check being used to impersonate real eduGAIN users?</h3>
<p>
Test accounts by the eduGAIN Access Check have a hard-coded domain set to "@access-check.edugain.org" that cannot be customized. Test accounts by the eduGAIN Access Check have a hard-coded domain set to "@access-check.edugain.org" that cannot be customized.
The eduGAIN Access Check will have the scope "access-check.edugain.org" in its published metadata. Therefore, an SP with enabled scope The eduGAIN Access Check will have the scope "access-check.edugain.org" in its published metadata. Therefore, an SP with enabled scope
check would not accept any eduPersonPrincipalName with a different scope than this. check would not accept any eduPersonPrincipalName with a different scope than this.
<br/><br/> </p>
The creation of eduGAIN Access Check test accounts is limited to administrators of an SP published in eduGAIN metadata. The SP admin validation process
relies on a standard email challenge sent to the declared technical contacts in the SP's official metadata.
<br/><br/>
Test identities can be used exclusively to access a single SP (the one of the verified SP admin). Authentication requests for other SPs are rejected.
......
...@@ -28,11 +28,5 @@ Service Provider you are administrator for. ...@@ -28,11 +28,5 @@ Service Provider you are administrator for.
<p> <p>
<br/><img alt="[% conf.app_name %] Basics" src="/resources/images/edugain_test_idp_basics.png"/> <br/><img alt="[% conf.app_name %] Basics" src="/resources/images/edugain_test_idp_basics.png"/>
</p> </p>
<h3>How is it ensured that users can only test their own service?</h3>
<p>[% conf.app_name %] exclusively allows creating test
accounts only to users who can receive challenge emails for email
addresses listed in the eduGAIN metadata for a particular Service Provider.
The test accounts can only be used to access one single service for
which a user proofed that he is administrator.
</p>
</div> </div>
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment