Webservice - documentation technique

Authorization Web Service

Introduction

The Email Authorization Web Service allows a targeted population to access the Career Center, in case an SSO is not available or sufficient to filter access.

Should I develop it ? If you need to tick the three boxes below, the answer is YES !

  • I want to restrict the access to my Career Center
  • My targeted population doesn’t have the same email adress
  • I can’t add the targeted population in my SSO

In case of any question, do not hesitate to contact us to : support.careercenter@jobteaser.com

1. Authorization

The webservice of Authorization MUST whitelist JobTeaser Server IP and MUST be protected by the HTTP Basic Auth.

1.1. Protocol Flow

  +--------+                                 +---------------+
  |        |                                 |               |
  | Career |--(A)- Authorization Request --->| Authorization |
  | Center |                                 |    Server     |
  |        |<-(B)- Authorization Response ---|               |
  +--------+                                 +---------------+

1.2. Authorization Endpoint

The Authorization Endpoint performs Authentication of the End-User. This is done by sending the End-User email to the Authorization Server’s Authorization Endpoint for Authentication and Authorization, using request parameters.

The Authorization Endpoint MUST be /authorize.

Communication with the Authorization Endpoint MUST utilize TLS. See Section 2 for more information on using TLS.

1.3. Authorization Request

Authorization Servers MUST support the use of the HTTP GET methods defined in [RFC2616] at the Authorization Endpoint.

Authorization Endpoint uses the following request parameters:

  • email REQUIRED. Authorization requests MUST have the email key. If the email value is not present, the behavior is entirely unspecified.

Example:

  GET /authorize?email=student@school.com HTTP/1.1
  Host: jobteaser.school.com

1.4 Authorization Response

1.4.1 Successful Authorization Response

Authorization Server MUST returns JSON response with 200 (success HTTP code), with the following parameters:

  • email REQUIRED. The email given on the Authorization Request.
  • authorised REQUIRED. Boolean to known if the End-User is authorized to access on the Carrer Center.

The following is a non-normative example successful response using this flow (with line wraps within values for display purposes only):

  HTTP/1.1 200 OK
  Content-Type: application/json
  Cache-Control: no-store
  Pragma: no-cache

  {
    "email": "student@school.com",
    "authorised": true
  }

A other example with a unauthorised answer:

  HTTP/1.1 200 OK
  Content-Type: application/json
  Cache-Control: no-store
  Pragma: no-cache

  {
    "email": "student@school.com",
    "authorised": false
  }

1.4.2. Authorization Error Response

The Authorization Server MUST returns JSON response with an error HTTP code (like: 400, 401, etc.), with the following parameters:

  • error REQUIRED. The error reason.
  • error_message OPTIONAL. The explain of this error, this message can be deplayed to the End-User.

The following is a non-normative example successful response using this flow (with line wraps within values for display purposes only):

  HTTP/1.1 200 OK
  Content-Type: application/json
  Cache-Control: no-store
  Pragma: no-cache

  {
    "error": "not_registred",
    "error_message": "The student is not registred inside our school.",
  }

2. TLS Requirements

Implementations MUST support TLS. Which version(s) ought to be implemented will vary over time, and depend on the widespread deployment and known security vulnerabilities at the time of implementation. At the time of this writing, TLS version 1.2 [RFC5246] is the most recent version, but has very limited actual deployment, and might not be readily available in implementation toolkits. TLS version 1.0 [RFC2246] is the most widely deployed version, and will give the broadest interoperability.

To protect against information disclosure and tampering, confidentiality protection MUST be applied using TLS with a ciphersuite that provides confidentiality and integrity protection.

Whenever TLS is used, a TLS server certificate check MUST be performed, per [RFC6125].

Cet article vous a-t-il été utile ?
Utilisateurs qui ont trouvé cela utile : 0 sur 0

Commentaires

0 commentaire

Vous devez vous connecter pour laisser un commentaire.