Page Comparison

CONFIGURACIÓN PREVIA NECESARIA

<add name="GeneXus.Http.GXOAuthAccessToken" verb="*" path="GXOAuthAccessToken.aspx" type="GeneXus.Http.GXOAuthAccessToken,GxClasses" />

<system.webServer>
  <bindings>
    <webHttpBinding>
      <binding name="CustomBinding" maxReceivedMessageSize="10485760">
        <security mode="Transport">
          <transport clientCredentialType="None" />
        </security>
       <readerQuotas maxStringContentLength="10485760" />
      </binding>
    </webHttpBinding>
    <basicHttpBinding>
      <binding name="CustomBinding" maxReceivedMessageSize="10485760">
        <security mode="Transport">
          <transport clientCredentialType="None" />
        </security>
        <readerQuotas maxStringContentLength="10485760" />
      </binding>
    </basicHttpBinding>
  </bindings>
</system.serviceModel>

CREACIÓN Y ASIGNACIÓN DE ROLES Y PERMISOS A USUARIO PARA ACCESO A LOS WEB SERVICE

Para esto es recomendable crear un usuario en el GeneXus Access Manager (GAM) para

permitir el acceso exclusivo a

• Roles y Permisos: Se debe crear un rol específico para el uso de web services con los permisos de los web services expuestos y este rol debe ser asignado al usuario que se utilizará para la conexión. Por cada web service expuesto sobre una transacción Genexus existen permisos relacionados, los cuales deben llevar el sufijo con el permiso otorgado, la estructura es

[Transaccion]_Service_[Tipo de Permiso]

Entre los tipos de permisos estánlos Web Services, a través de dicho usuario, adicional es necesario que este tenga los Roles y Permisos necesarios para acceder a las transacciones que hemos decidido exponer para que sea consumidas vía Web Services por aplicaciones de terceros (Clientes, Proveedores, Contratistas, etc).

Para ello primero validamos que con una cuenta administradora en el GeneXus Access Manager (GAM),a través del GAM Web Backend (o GAM Web Backoffice) (Existen varias interfaz para ello pero se considera esta la mas practica), que el usuario existe o si debemos crear uno para el uso de los Web Services, tal como se indico en el párrafo anterior, se recomienda crear uno exclusivo para ello.

Image Added

Luego se debe asignar o validar que el Rol al que se le asignaran los permiso de acceso sea el Rol principal (En caso de NO ser el principal aparecerá en la Columna Main la opción “Set Main”).

Image Added

Luego se verifique, en la opción de edición de Roles del GAM Web Backend (o GAM Web Backoffice), que la aplicación en la cual se asignaran los Roles y Permisos sea nuestra instancia principal de la Aplicación SIFCO WEB.

Image Added

SIFCO WEB a través de GAM, genera un conjunto de permisos automáticos de las diferentes transacciones habilitadas en nuestra Aplicación SIFCO WEB, solo debemos escoger cuales serán expuestas o consumidas a través de Web Services por este usuario y a través de cuales métodos. Los mismos están descritos bajo la siguiente nomenclatura, y donde el Prefijo depende de la Transacción (Business Component o componente de negocio), y el sufijo del método RESTful que se va a utilizar.

[Tansacciones]_Services_[Tipo de Permiso = {execute, insert, delete, update, FullControl}]

Image Added

Luego se asignan los Tipos de Permisos de Acceso que tendrá este Rol a cada transacción.

Image Added

Por ultimo se valida que este Rol, sea el Rol principal del usuario creado o asignado para el acceso a las transacciones vía sistema RESTful.

Image Added

INFORMACIÓN ADICIONAL

Entre los tipos de permisos asociados a la transacciones y método a utilizar tenemos:

• Execute
  Permite operaciones GET

• Insert
  Permite operaciones POST

• Delete
  Permite operaciones DELETE

• Update
  Permite operaciones PUT

• FullControl
  Permite realizar GET, POST, PUT y DELETE sobre el web service.

WEB SERVICE DE AUTENTICACIÓN

• ACCESS TOKEN

Para obtener el token de acceso es necesario realizar POST con los parámetros

Image Removed

Donde los parámetros client_id y client_secret deben obtenerse de los parámetros de la aplicación en el GAM

esta información puede ser revisada en el menú Configuración - Seguridad - Configuración de la Aplicación

Image Removed

PETICIÓN DE ACCESO

• POST a

HTTP://<SERVER>/<APPDIR>/oauth/access_token

Incluyendo en el body:

client_id=1234561ad52a42919a221bc796d0d6b0&client_secret=1111114313d243dd987b3aadb250e63b&granttype=password&scope=FullControl&username=admin&password=admin123

• Como respuesta se obtendrá un JSON con el token de acceso el cual deberá utilizarse en el encabezado de petición de consumo de los objetos expuestos

{ 
"access token" : "c9919e10e118"
"scope" : "FullControl"
}

CONSUMO DE WEB SERVICE

• Petición con la estructura:

HTTP://<SERVER>/<APPDIR>/rest/WEB_SERVICE/PARM_1/PARM_2/PARM_N

• Encabezados obligatorios:

“Content-Type”, ”application/json”
“Authorization”, “OAuth ” + access_token
“GENEXUS-AGENT”, “SmartDevice Application”

• Web Service.

Adicionalmente los tipos de permisos de acceso a nivel de Rol de usuario son:

• Allow:
  Un usuario que tiene un rol con un permiso de Tipo de acceso = Allow (Permitir) tendrá este permiso a menos que se le haya otorgado este permiso con Tipo de acceso = Deny (Denegar), o tenga otro rol donde se niegue el mismo permiso.

• Deny:
  Un usuario que tiene un rol con un permiso de Tipo de acceso = Deny (Denegar) no tendrá este permiso independientemente de si el permiso está permitido a nivel de aplicación (por defecto) o si tiene otro rol donde el permiso está permitido. La única forma en que el usuario puede obtener este permiso es con Tipo de acceso = Allow (Permitir).

• Restricted
  Si un permiso está restringido a la función de un usuario, él no tiene este permiso a menos que el usuario tenga este permiso con Tipo de acceso = Allow (Permitir) o tenga otra función donde se permita el mismo permiso.