Id

13352

Keyword

CHXUA_X_SERV_USR_AUTH_USR

Name

CHXUA_X_SERV_USR_AUTH_USR

Version

1.1

Test Author

wbars

Last modifier

vhofman

Status

ready

Type

master type

Is external tool ?

Is Orchestrable

is Validated ?

Peer Type

No Peer

Test validated by

NicolasBailliet

Test permanent link

https://ehealthsuisse.ihe-europe.net/gazelle/test.seam?id=13352

Short Description

Verify X-Service User is able to initiate and run a valid CH:XUA Authenticate User transaction with the simulated User Authentication Provider using the artifact binding.

Last changed

4/11/24 8:57:39 AM

Special Instructions

WARNING : X-Service User must be already registered in the IdP Simulator for this test case.

User Authentication Provider (IdP) configuration (entityIDs, metadata, SSO endpoints, Artifact resolution endpoints, Testing users registered in the IdP) is available here (IdP simulator tab).

TLS must be used.

The monitor must collect the evidences directly on the machine (see the Evaluation section for more details).

Description

The goal of this test is to verify that the X-Service User is able to perform a valid CH:XUA Authenticate User transaction with a User Authentication Provider (IdP) using the Direct RP initiated transaction with SAML HTTP POST or Redirect binding, alongside Artifact Binding.

Proceedings

1. The X-Service-User operator will try to access a protected resource that requires user authentication.
2. The X-Service-User will then send an SAML Authentication request to the User Authentication Provider (IdP) and be redirected to the user credential form.
3. The X-Service-User operator will input the credentials and validate the form.
4. The User Authentication Provider (IdP) will create an authentication token (assertion) and deliver the artifact ID to the X-Service-User.
5. The X-Service-User will then request for the artifact resolution to the User Authentication Provider (IdP)
6. And the User Authentication Provider (IdP) will return the previously created assertion and authentication response to the X-Service-User.
7. Finally the X-Service User will allow the operator to access the requested resource.

Evidences

Alongside this process please collect the following evidences :

• EntityID of both parties and their endpoints
  
• Screenshot of the X-Service User application when not logged in
• The SAML authentication request
• Screenshot of the IdP credentials form/challenge
• The HTTP Redirect or HTML form POST response containing the artifact Id
  
• The Artifact Resolve request
• The Artifact Resolve response
  
• Screenshot of the X-Service User application while logged in and accessing the protected resource

Input those evidences in the right tests step and mark the test to be verified.

Live demo

A good demonstration :

1. Shows what a user not logged in can access in your system.
2. Asks for login or for a protected resource
3. Shows that the user is redirected on the IdP authentication form.
4. Once input, shows the user is well logged in and can access the requested resource or is able to perform more actions.
5. If possible for your logging system, you can also show live request/responses

Evaluation

Monitor will evaluate the test on several points

1. All requested evidences must have been uploaded on the right test steps. To collect the evidences, the monitor must connect to the platform's server using ssh and find the four following messages in /opt/shibboleth-idp/logs/idp-process.log :
   
2. AuthnRequest
   
   • ProtocolBinding must be "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
     
   • Destination (if present) must be IdP SSO endpoint.
   • Issuer must be the X-Service User entityID
     
   • Please note the AuthnRequest ID to compare it with the inResponseTo in the SAML response.
   • Please note the AssertionConsumerServiceURL for later use in HTTP Redirect or HTML from POST. 
3. HTTP Redirect or HTML form POST (issued by IdP as response to the credential POST)
   
   • The Location (HTTP Redirect) or the HTML form action (HTML form POST) must be the X-Service User Assertion Consumer endpoint as defined using AssertionConsumerServiceURL in the AuthRequest
     
   • The Location must have the SAMLart as query parameter (HTTP Redirect) or the HTML form must have an hidden input SAMLart (HTTP form POST)
     
   • Please Note the SAMLart (artifact Id) value to compare it with the Artifact in the ArtifactResolveRequest.
     
4. ArtifactResolveRequest
   • Destination must be IdP artifact resolution endpoint
   • Issuer must be the X-Service User entityID
   • Artifact must be the artifact Id.
     
   • Please note the ArtifactResolveRequest ID to compare it with the inResponseTo in the ArtifactResolveResponse
5. ArtifactResolveResponse
   • ArtifactResolveResponse inResponseTo must be ArtifactResolveRequest ID
   • The ArtifactResolveResponse Issuer may be present, if so it must be the IdP entityID
   • ArtifactResolveResponse must contains the SAML Response to the initial authentication request.
   • The SAML Response inResponseTo must be AuthnRequest ID
   • The SAML Response Issuer must be IdP EntityID
   • The SAML Response must have StatusCode Value equals to urn:oasis:names:tc:SAML:2.0:status:Success
   • The SAML Response must contain an SAML Assertion
   • The SAML Assertion Issuer must be the IdP EntityID
   • The SAML Assertion SHALL be signed
   • The SAML Assertion Conditions must have the notBefore attribute equivalent to the Assertion IssueInstant attribute and the NotOnOrAfter attribute that gives at longest 5 minutes of validity.
   • The SAML Assertion Attribute statement must contain :
     • familyname
     • firstname
     • gender
     • dateofbirth
     • identno
6. Monitor should request a live demo to the X-Service User operator. It must be a successful authentication with access to resources granted, and what is seen in the demo must match the content of the uploaded screenshots.