Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "Applications on Demand Service - information for providers"

From EGIWiki
Jump to navigation Jump to search
Line 1: Line 1:
{{Template:Op menubar}}  
{{Template:Op menubar}} {{Template:LTOS_menubar}} {{TOC_right}}  
{{Template:LTOS_menubar}}
{{TOC_right}}  


<br> '''This page provides information about the '[http://access.egi.eu EGI platform for the Long-tail of science]'. The long-tail of science refers to the individual researchers and small laboratories who - opposed to large, expensive collaborations - do not have access to computational resources and online services to manage and analyse large amount of data. This EGI platform allows individual researchers and small research teams to perform compute and data-intensive simulations on large, distributed networks of computers in a user friendly way. If you are interested in the activity that developed and now maintains the platform, please jump to the [[Long-tail of science activity|Long-tail of science activity]] page.'''  
<br> '''This page provides information about the '[http://access.egi.eu EGI platform for the Long-tail of science]'. The long-tail of science refers to the individual researchers and small laboratories who - opposed to large, expensive collaborations - do not have access to computational resources and online services to manage and analyse large amount of data. This EGI platform allows individual researchers and small research teams to perform compute and data-intensive simulations on large, distributed networks of computers in a user friendly way. If you are interested in the activity that developed and now maintains the platform, please jump to the [[Long-tail of science activity|Long-tail of science activity]] page.'''  
Line 11: Line 9:
= Guide for providers  =
= Guide for providers  =


*Science gateway and resource providers must accept and follow the platform security policy: https://wiki.egi.eu/wiki/SPG:Drafts:LToS_Service_Scoped_Security_Policy
*Science gateway and resource providers must accept and follow the platform security policy: https://documents.egi.eu/public/ShowDocument?docid=2734&nbsp;
*Science gateway providers must sign OLA with EGI.eu.
*Science gateway providers must integrate with the User Registration Portal to enable the single sign-on capability for users.  
*Science gateway providers must integrate with the User Registration Portal to enable the single sign-on capability for users.  
*Science gateway providers must integrate with the per-user subproxy solution to offer traceable user authentication towards the e-infrastructure VO.  
*Science gateway providers must integrate with the per-user subproxy solution to offer traceable user authentication towards the e-infrastructure VO.  
Line 26: Line 25:


<br>  
<br>  
<div><div>'''Authorization procedure Unity with Client:'''</div><div>'''<br>'''</div><div>1] The Client sends a request to the OpenID Provider</div><div><br></div><div>address:&nbsp;[https://unity.egi.eu/oauth2-as/oauth2-authz https://unity.egi.eu/oauth2-as/oauth2-authz]</div><div><br></div><div>parameters:</div><div>response_type:code</div><div>redirect_uri:&nbsp;[[Redirect url]]</div><div>client_id:unity-oauth-egrant</div><div>state:&nbsp;[[You should generate your own state eg. md5(uniqid(rand(), TRUE));]]</div><div>scope:profile openid&nbsp;</div><div><br></div><div>example:</div><div>&nbsp;&nbsp;[https://unity.egi.eu/oauth2-as/oauth2-authz https://unity.egi.eu/oauth2-as/oauth2-authz]</div><div>&nbsp; &nbsp; response_type=code</div><div>&nbsp; &nbsp; &amp;client_id=123123123</div><div>&nbsp; &nbsp; &amp;redirect_uri=https%3A%2F%2Fclient.pl%2Fauth</div><div>&nbsp; &nbsp; &amp;scope=openid%20profile</div><div>&nbsp; &nbsp; &amp;state=a123a123a123</div><div><br></div><div><br></div><div>2] Authorization Server authenticates the End-User.</div><div>3] Authorization Server obtains End-User Consent/Authorization.</div><div>4] Authorization Server sends the End-User back to the redirect uri from the first request ([[Redirect url]]) with code.</div><div><br></div><div>example of the response</div><div><br></div><div>Location:&nbsp;[https://client.pl/auth https://client.pl/auth]?</div><div>&nbsp; &nbsp; code=uniquecode123</div><div>&nbsp; &nbsp; &amp;state=a123a123a123</div><div><br></div><div><br></div><div><br></div><div>5] Client sends the code to the Token Endpoint to receive an Access Token and ID Token in the response.</div><div><br></div><div>POST /token HTTP/1.1</div><div>&nbsp; Host:&nbsp;[http://client.pl/ client.pl]</div><div>&nbsp; Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW</div><div>&nbsp; Content-Type: application/x-www-form-urlencoded</div><div><br></div><div>&nbsp; grant_type=authorization_code&amp;code=uniquecode123</div><div>&nbsp; &nbsp; &amp;redirect_uri=https%3A%2F%2Fclient.pl%2Fauth</div><div><br></div><div><br></div><div><br></div><div><br></div><div>6] Client validates the tokens and retrieves the End-User's Subject Identifier.</div><div><br></div><div>example:</div><div><br></div><div>&nbsp; HTTP/1.1 200 OK</div><div>&nbsp; Content-Type: application/json</div><div>&nbsp; Cache-Control: no-store</div><div>&nbsp; Pragma: no-cache</div><div>&nbsp; {</div><div>&nbsp; &nbsp;"access_token":"accessToken123",</div><div>&nbsp; &nbsp;"token_type":"Bearer",</div><div>&nbsp; &nbsp;"expires_in":3600,</div><div>&nbsp; &nbsp;"refresh_token":"refreshToken123",</div><div>&nbsp; &nbsp;"id_token":"idToken123123"</div><div>&nbsp; }</div><div><br></div><div>You should decode id_token and make some validation (more information:&nbsp;[http://openid.net/specs/openid-connect-basic-1_0.html http://openid.net/specs/openid-connect-basic-1_0.html])</div><div><br></div><div><br></div><div>7] Client Gets some information from userpoint endpoint ([https://unity.egi.eu/oauth2/userinfo https://unity.egi.eu/oauth2/userinfo])</div><div><br></div><div>example</div><div>[https://unity.egi.eu/oauth2/userinfo?schema=openid&access_token=accessToken123 https://unity.egi.eu/oauth2/userinfo?schema=openid&amp;access_token=accessToken123]"</div><div><br></div><div><br></div><div>8] User gets information about user such as email or name in json format</div><div><br></div><div><br></div><div><br></div><div>important data:</div><div>unity.server.clientId=&nbsp; [YOUR CLIENT ID]<br>unity.server.clientSecret= [YOUR SECRET KEY]<br></div><div>unity.server.authorize=[https://unity.egi.eu/oauth2-as/oauth2-authz https://unity.egi.eu/oauth2-as/oauth2-authz]</div><div>unity.server.token=[https://unity.egi.eu/oauth2/token https://unity.egi.eu/oauth2/token]</div><div>unity.server.base=[https://unity.egi.eu/ https://unity.egi.eu]</div><div><br></div><div>full configuration:</div><div>[https://unity.egi.eu/oauth2/.well-known/openid-configuration https://unity.egi.eu/oauth2/.well-known/openid-configuration]</div></div><div><br></div>  
<div><div>'''Authorization procedure Unity with Client:'''</div><div>'''<br>'''</div><div>1] The Client sends a request to the OpenID Provider</div><div><br></div><div>address:&nbsp;[https://unity.egi.eu/oauth2-as/oauth2-authz https://unity.egi.eu/oauth2-as/oauth2-authz]</div><div><br></div><div>parameters:</div><pre>response_type:code
 
redirect_uri: [[Redirect url]]
 
client_id:unity-oauth-egrant
 
state: [[You should generate your own state eg. md5(uniqid(rand(), TRUE));]]
 
scope:profile openid </pre><div><br></div><div>example:</div><pre> [https://unity.egi.eu/oauth2-as/oauth2-authz https://unity.egi.eu/oauth2-as/oauth2-authz]
 
    response_type=code
 
    &amp;client_id=123123123
 
    &amp;redirect_uri=https%3A%2F%2Fclient.pl%2Fauth
 
    &amp;scope=openid%20profile
 
    &amp;state=a123a123a123</pre><div><br></div><div><br></div><div>2] Authorization Server authenticates the End-User.</div><div>3] Authorization Server obtains End-User Consent/Authorization.</div><div>4] Authorization Server sends the End-User back to the redirect uri from the first request ([[Redirect url]]) with code.</div><div><br></div><div>example of the response</div><pre>
 
Location: [https://client.pl/auth https://client.pl/auth]?
 
    code=uniquecode123
 
    &amp;state=a123a123a123</pre><div><br></div><div><br></div><div><br></div><div>5] Client sends the code to the Token Endpoint to receive an Access Token and ID Token in the response.</div><div><br></div><pre>POST /token HTTP/1.1
 
  Host: [http://client.pl/ client.pl]
 
  Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
 
  Content-Type: application/x-www-form-urlencoded
 
 
  grant_type=authorization_code&amp;code=uniquecode123
 
    &amp;redirect_uri=https%3A%2F%2Fclient.pl%2Fauth</pre><div><br></div><div><br></div><div><br></div><div><br></div><div>6] Client validates the tokens and retrieves the End-User's Subject Identifier.</div><div><br></div><div>example:</div><pre>
 
  HTTP/1.1 200 OK
 
  Content-Type: application/json
 
  Cache-Control: no-store
 
  Pragma: no-cache
 
  {
 
  "access_token":"accessToken123",
 
  "token_type":"Bearer",
 
  "expires_in":3600,
 
  "refresh_token":"refreshToken123",
 
  "id_token":"idToken123123"
 
  }</pre><div><br></div><div>You should decode id_token and make some validation (more information:&nbsp;[http://openid.net/specs/openid-connect-basic-1_0.html http://openid.net/specs/openid-connect-basic-1_0.html])</div><div><br></div><div><br></div><div>7] Client Gets some information from userpoint endpoint ([https://unity.egi.eu/oauth2/userinfo https://unity.egi.eu/oauth2/userinfo])</div><div><br></div><div>example</div><div>[https://unity.egi.eu/oauth2/userinfo?schema=openid&access_token=accessToken123 https://unity.egi.eu/oauth2/userinfo?schema=openid&amp;access_token=accessToken123]"</div><div><br></div><div><br></div><div>8] User gets information about user such as email or name in json format</div><div>
important data:
</div><pre>
unity.server.clientId= [YOUR CLIENT ID]
unity.server.clientSecret= [YOUR SECRET KEY]
 
unity.server.authorize=[https://unity.egi.eu/oauth2-as/oauth2-authz https://unity.egi.eu/oauth2-as/oauth2-authz]
 
unity.server.token=[https://unity.egi.eu/oauth2/token https://unity.egi.eu/oauth2/token]
 
unity.server.base=[https://unity.egi.eu/ https://unity.egi.eu]</pre><div><br></div><div>full configuration:</div><div>[https://unity.egi.eu/oauth2/.well-known/openid-configuration https://unity.egi.eu/oauth2/.well-known/openid-configuration]</div></div><div><br></div>  
==== OpenId Connect for Liferay  ====
==== OpenId Connect for Liferay  ====


Line 103: Line 169:


<span style="font-size: 13.28px; line-height: 19.92px; font-weight: normal;">Any EGI</span><span style="font-size: 13.28px; font-weight: normal; line-height: 1.5em;">&nbsp;</span><span style="line-height: 19.92px; font-size: 13.28px; font-weight: normal; background-color: initial;">resource
<span style="font-size: 13.28px; line-height: 19.92px; font-weight: normal;">Any EGI</span><span style="font-size: 13.28px; font-weight: normal; line-height: 1.5em;">&nbsp;</span><span style="line-height: 19.92px; font-size: 13.28px; font-weight: normal; background-color: initial;">resource
</span>
</span>  


  provider can join the platform to offer capacity for members of the  
  provider can join the platform to offer capacity for members of the  

Revision as of 17:43, 1 April 2016

Main EGI.eu operations services Support Documentation Tools Activities Performance Technology Catch-all Services Resource Allocation Security


Applications on Demand Service menu: Home • Documentation for providers • Documentation for developers • Architecture





This page provides information about the 'EGI platform for the Long-tail of science'. The long-tail of science refers to the individual researchers and small laboratories who - opposed to large, expensive collaborations - do not have access to computational resources and online services to manage and analyse large amount of data. This EGI platform allows individual researchers and small research teams to perform compute and data-intensive simulations on large, distributed networks of computers in a user friendly way. If you are interested in the activity that developed and now maintains the platform, please jump to the Long-tail of science activity page.



Guide for providers

  • Science gateway and resource providers must accept and follow the platform security policy: https://documents.egi.eu/public/ShowDocument?docid=2734 
  • Science gateway providers must sign OLA with EGI.eu.
  • Science gateway providers must integrate with the User Registration Portal to enable the single sign-on capability for users.
  • Science gateway providers must integrate with the per-user subproxy solution to offer traceable user authentication towards the e-infrastructure VO.
  • Science gateways must implement user resource usage quota (to prohibit a user consuming all the resources from the platform).
  • Resource providers must support the per-user subproxy solution and join the e-infrastructure VO.

The below subsections provide guidance to complete these steps.

How to connect a science gateway to the platform

Connecting the science gateway with the User Registration Portal


Client service Registration

1. Open the GGUS ticket to operations that include return URIs

2. UNITY team send Client clientID and secretKey


Authorization procedure Unity with Client:

1] The Client sends a request to the OpenID Provider


parameters:
response_type:code

redirect_uri: [[Redirect url]]

client_id:unity-oauth-egrant

state: [[You should generate your own state eg. md5(uniqid(rand(), TRUE));]]

scope:profile openid

example:
  [https://unity.egi.eu/oauth2-as/oauth2-authz https://unity.egi.eu/oauth2-as/oauth2-authz]

   response_type=code



   &client_id=123123123



   &redirect_uri=https%3A%2F%2Fclient.pl%2Fauth



   &scope=openid%20profile


    &state=a123a123a123


2] Authorization Server authenticates the End-User.
3] Authorization Server obtains End-User Consent/Authorization.
4] Authorization Server sends the End-User back to the redirect uri from the first request (Redirect url) with code.

example of the response
Location: [https://client.pl/auth https://client.pl/auth]?



   code=uniquecode123


    &state=a123a123a123



5] Client sends the code to the Token Endpoint to receive an Access Token and ID Token in the response.

POST /token HTTP/1.1

 Host: [http://client.pl/ client.pl]



 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW



 Content-Type: application/x-www-form-urlencoded








 grant_type=authorization_code&code=uniquecode123


    &redirect_uri=https%3A%2F%2Fclient.pl%2Fauth




6] Client validates the tokens and retrieves the End-User's Subject Identifier.

example:
 HTTP/1.1 200 OK



 Content-Type: application/json



 Cache-Control: no-store



 Pragma: no-cache



 {



  "access_token":"accessToken123",



  "token_type":"Bearer",



  "expires_in":3600,



  "refresh_token":"refreshToken123",



  "id_token":"idToken123123"


  }

You should decode id_token and make some validation (more information: http://openid.net/specs/openid-connect-basic-1_0.html)


7] Client Gets some information from userpoint endpoint (https://unity.egi.eu/oauth2/userinfo)

example


8] User gets information about user such as email or name in json format

important data: 

unity.server.clientId=  [YOUR CLIENT ID]
unity.server.clientSecret= [YOUR SECRET KEY]

unity.server.authorize=[https://unity.egi.eu/oauth2-as/oauth2-authz https://unity.egi.eu/oauth2-as/oauth2-authz]

unity.server.token=[https://unity.egi.eu/oauth2/token https://unity.egi.eu/oauth2/token]

unity.server.base=[https://unity.egi.eu/ https://unity.egi.eu]

full configuration:

OpenId Connect for Liferay

OpenId Connect for Liferay is a very rough but effective implementation of the OpenId connect protocol for Liferay. Use this module to authenticate with any OpenId Connect provider.

Connecting the science gateway with per-user subproxies

The platform uses per-user subproxies (PSUPs) for user authentication. Any connected science gateway must generate per-user sub proxies for their users and must use these for any interaction with VO resources on behalf of the users. A gateway can generate PSUPs in two ways:

  1. . From a robot certificate that is physically hosted on the gateway server itself. OR
  2. . From a remote robot certificate that is hosted in the e-Token Server by INFN Catania.

We recommend you to choose the first option. If there is an IGTF CA in your country which issues robot certificates then obtain a robot from this CA. If such robots are not available in your country or region, then EGI can issue a robot for you from the SEEGRID catch-all CA. The next subsections provide details information to complete these steps.

Generic requirements

The Per-User Sub-Proxy (PUSP) and End-Entity Certificate (EEC) must satisfy the following requirements:

  1. The EEC is a valid robot certificate:
  2. The PUSP is RFC 3820 compliant, i.e. no legacy GT2 or GT3 proxies
  3. The PUSP is the first proxy delegation
  4. If the same user enters via the same portal, he must get the same PUSP DN
  5. No two distinct identified users will have the same PUSP DN.

A robot EEC that generates PUSP credentials SHOULD NOT be used for any other purpose; for example, it should not be used to generate non-PUSP proxy credentials and should not be use for direct authenticating.

The machine/service that will take care of PUSP generation and management should respect the following rules:

  1. Documented response procedures in case of incidents (that are periodically tested).
  2. A listed/accredited CSIRT team.
  3. Internal risk assessment and an actuarial team to calculate the effective risk

Using a robot certificate from your national IGTF CA

  1. Obtain a robot certificate from your national IGTF Certification Authority following the instructions here.
  2. Register the robot in the vo.access.egi.eu VO: https://perun.metacentrum.cz/cert/registrar/?vo=vo.access.egi.eu
  3. Generate proxies from the robot using this script: https://ndpfsvn.nikhef.nl/viewvc/mwsec/trunk/lcmaps-plugins-robot/tools/

Obtaining a robot certificate from EGI catch-all CA

  1. Contact long-tail-support@mailman.egi.eu and send a short description of your gateway service and the way it would be integrated with platform resources. The team will arrange a robot certificate for your gateway from the SEEGRID CA (which operates as a 'catch-all' CA in EGI) and will register this in the VO and in the e-Token Server in Italy.
  2. Register the robot in the vo.access.egi.eu VO: https://perun.metacentrum.cz/cert/registrar/?vo=vo.access.egi.eu
  3. Generate proxies from the robot using this script: https://ndpfsvn.nikhef.nl/viewvc/mwsec/trunk/lcmaps-plugins-robot/tools/

Instructions to use the e-Token Server

  1. Contact long-tail-support@mailman.egi.eu and send a short justification why you would like to use the eToken server (instead of hosting the robot certificate locally). Describe your gateway service and the way it would be integrated with platform resources. The team will arrange a robot certificate for your gateway from the SEEGRID CA and will register it in vo.access.egi.eu.
  2. Provide long-tail-support@mailman.egi.eu with the static IP address of your gateway server, so proxy requests can be authorized from this address on the e-Token Server.
  3. Generate proxies from the e-Token server following this guideline:

There are two available e-Token Server instances for availability and reliability reasons:

  • etokenserver.ct.infn.it
  • etokenserver2.ct.infn.it

The following rest API is available to get a PUSP given a unique identifier: 

https://[eToken Server instance]:8443/eTokenServer/eToken/[Robot Certificate ID]?voms=[VO]:/[VO]&proxy-renewal=[true|false]&disable-voms-proxy=[true|false]&rfc-proxy=[true|false]&cn-label=user:[user unique identifier]
  • Robot cetificate ID: it is the ID of your robot certificate in the e-Token server. It will be generated after the setup of your robot into the e-Token Server.
  • VO: the VO you want to use to perform any action on the EGI infrastructure. The robot certificate must be a member of this VO.
  • proxy-renewal: this option is used to enable (true) or disable (false) the automatic registration of a long-term proxy into a MyProxy Server.
  • disable-voms-proxy: this option is used to generate plain (true) or VOMS proxy certificate (false).
  • rfc-proxy: this option is used to generate standard RFC proxies (true) or legacy proxies (false).
  • cn-label: this option is used to generate a PUSP for the given unique identifier.

below an example: 

https://[eToken Server instance]:8443/eTokenServer/eToken/27br90771bba31acb942efe4c8209e69?voms=training.egi.eu:/training.egi.eu&proxy-renewal=false&disable-voms-proxy=false&rfc-proxy=true&cn-label=user:test1

Connecting the gateway with the EGI monitoring system

...

How to join as a resource provider

Any EGI resource 

provider can join the platform to offer capacity for members of the

long-tail of science. The site needs to run one of the supported grid or 

cloud middleware software, enable per-user sub-proxies (for user

authentication and authorisation), and join the vo.access.egi.eu Virtual Organisation. The next subsections provide instructions on how to enable per-user sub-proxies on EGI sites. Please email long-tail-support@egi.eu if you wish to join as a resource provider.

In order to provide authorization to the users of the LToS VO, a couple of DNs (Distinghished Names) are required to be configured on the services to be enabled. For instance, for the CREAM CE the usual grid-mapfile is the place where to add them, for OpenStack it's /etc/keystone/voms.json. You can find below the instructions for each service.

The following Robot Certificate DNs must be configured: 

/DC=EU/DC=EGI/C=HU/O=Robots/O=MTA SZTAKI/CN=Robot:zfarkas@sztaki.hu
/C=IT/O=INFN/OU=Robot/L=Catania/CN=Robot: Catania Science Gateway  - Roberto Barbera

Instructions for OpenStack providers

Keystone-VOMS has support for per-user subproxies in the special branch called subproxy_support available in the github repository https://github.com/enolfc/keystone-voms (code is in progress of being integrated into the main branch of Keystone-VOMS). You can install the code from the repository following these instructions: 

 git clone -b subproxy_support https://github.com/enolfc/keystone-voms.git
 cd keystone-voms
 pip install .

Configuration and deployment of the plugin does not change from the normal Keystone-VOMS plugin, follow the Keystone-VOMS documentation to deploy it.

There are new parameters to configure in your keystone config file, under the [voms] section:

  • allow_subproxy, should be set to True for enabling PUSP support.
  • subproxy_robots, should be set to * (recommended) or to a list of the DNs that are allowed to create PUSP in the system.
  • subproxy_user_prefix, determines the expected prefix for the PUSP user specification. It is safe to leave it undefined so the default value (CN=eToken is used.

Instruction for gLite providers

There is an EGI manual that shows how to set up a per-user sub-proxy to allow identification of the individual users under a common robot certificate. You can find the guide here: https://wiki.egi.eu/wiki/MAN12

Instruction for OpenNebula providers

OpenNebula sites are not yet supported in the platform.

How to join the user support team

If you wish to support platform users from your country, region or scientific disciplinary area, then please email long-tail-support@egi.eu. We can train you and then register you as a supporter in our team.

Retrieved from "https://wiki.egi.eu/w/index.php?title=Applications_on_Demand_Service_-_information_for_providers&oldid=86849"