Framework pre-configurado para la implementación del estandar OAuth 1.0a (http://oauth.net/core/1.0a/) en aplicaciones WEB mediante comunicación REST
-
JDK 1.7 (o superior)
-
MAVEN 3.x
-
Servidor de aplicaciones JEE6 compatible
-
Aplicación de login que auspicie de proveedor de identidad ('IDP'), aplicación que provee los tokens ('SP') y aplicación que expone servicios REST segurizados.
-
Model (muralla-model), el cual contiene las clases e interfaces de modelo de datos que se utilizan para enviar/recibir información, como así también algunos utilitarios
-
Service (muralla-service), el cual contiene las interfaces de servicios necesarios para el guardado y recuperación de los elementos (tokens, consumers, etc)
-
Resource (muralla-resource), el cual contiene los componentes JAX-RS para la obtención y verificación de tokens
-
Model JPA (muralla-model-jpa), el cual contiene una implementación de gestión de tokens utilizando una base de datos SQL como fuente de datos. Tener en consideración que para utilizar este componente se debe contar con un persistence.xml para poder utilizar entidades JPA2.
-
Service JPA (muralla-service-jpa), el cual contiene servicios de operaciones con base de datos SQL. Este componente utiliza una unidad de persistencia llamada 'muralla-security-oauth'
-
OAuth utils (muralla-resource-utils), el cual contiene servicios REST para firmar un request en base a los datos provistos o dar de alta consumidores. Tener en cuenta que este componente es un punto crítico por lo que las cuestiones de seguridad en donde el mismo se despliegue dependerá de la aplicación que lo contenga.
-
OAuth interceptor (muralla-resource-intercept), el cual contiene un interceptor que captura los pedidos REST para validar y autorizar la ejecución de cada método.
Para comenzar a interactuar y gestionar las autorizaciones mediante la utilización de tokens, es preciso:
-
Descargar el proyecto y compilarlo
mvn clean install
-
En el pom.xml que corresponde a la aplicación 'IDP' agregar la siguiente dependencia:
<dependency> <groupId>org.security.muralla</groupId> <artifactId>muralla-resource-auth</artifactId> <version>${muralla.version}</version> </dependency><dependency> <groupId>org.security.muralla</groupId> <artifactId>muralla-service-jpa</artifactId> <version>${muralla.version}</version> </dependency> -
En el pom.xml que corresponde a la aplicación 'SP' agregar la siguiente dependencia:
<dependency> <groupId>org.security.muralla</groupId> <artifactId>muralla-resource-gen</artifactId> <version>${muralla.version}</version> </dependency><dependency> <groupId>org.security.muralla</groupId> <artifactId>muralla-service-jpa</artifactId> <version>${muralla.version}</version> </dependency> -
En el pom.xml que corresponde a la aplicación que posee los servicios a segurizar:
<dependency> <groupId>org.security.muralla</groupId> <artifactId>muralla-resource-intercept</artifactId> <version>${muralla.version}</version> </dependency><dependency> <groupId>org.security.muralla</groupId> <artifactId>muralla-service-jpa</artifactId> <version>${muralla.version}</version> </dependency> -
En el pom.xml que corresponde a la aplicación donde se quiera desplegar los utilitarios OAuth (opcionales):
<dependency> <groupId>org.security.muralla</groupId> <artifactId>muralla-resource-utils</artifactId> <version>${muralla.version}</version> </dependency><dependency> <groupId>org.security.muralla</groupId> <artifactId>muralla-service-jpa</artifactId> <version>${muralla.version}</version> </dependency> -
Generar los binarios de el/las aplicaciones
-
Desplegar el/los binarios en el contenedor de aplicaciones
Una vez construidos los componentes y desplegados correctamente en el contenedor de aplicaciones, el framework desplegará el siguiente conjunto de servicios REST:
URL que se utilizará para la solicitud de un token NO autorizado. En el mismo deberán ser enviado en el HEADER todos los parámetros requeridos por el estandar y firmados con la clave del consumidor. Tanto la "oauth_consumer_key" como la clave serán provistas por el proveedor del servicio de OAuth.
-
Request
POST: /{mySPapp}/{myRestBind}/oauth/request_token
HOST: {hostname}:{port}
HEADER: Authorization: OAuth oauth_consumer_key="mySPapp",oauth_signature_method="HMAC-SHA1",oauth_timestamp="1234567",oauth_nonce="abc123",oauth_version="1.0",oauth_signature="z9%252FwPeNNLKw%252BhRNg0LwpkaMROz8%253D"
-
Response
TYPE: TEXT/PLAIN
CONTENT: oauth_token={token1}&oauth_token_secret={token1Secret}&oauth_callback_confirmed=true
URL en la cual el usuario, mediante la utilización del token obtenido en el paso anterior, autorizará la aplicación y obtendra un valor de verificación.
-
Request
GET: /{myIDPapp}/{myRestBind}/oauth/authorize?oauth_token=token1
HOST: {hostname}:{port}
-
Response
TYPE: TEXT/PLAIN
CONTENT: 260390798
URL que es utilizada para la solicitud de un token de acceso, el cual será el que se utilizará para realizar los pedidos a los recursos segurizados. Los parámetros enviados en este POST deberán ser firmados por la unión de la clave del consumidor y la clave enviada por el sistema en la respuesta anterior. Para nuestro caso de ejemplo, "token1Secret" por lo que si asumimos que la clave del consumidor es "secret", entonces, la nueva clave sería: secret&token1Secret
-
Request
POST: /{mySPapp}/{myRestBind}/oauth/access_token
HOST: {hostname}:{port}
HEADER: Authorization: OAuth oauth_version="1.0", oauth_nonce="908433656", oauth_signature_method="HMAC-SHA1", oauth_consumer_key="mySPapp", oauth_token="token1", oauth_verifier="260390798", oauth_timestamp="1435322081"
-
Response
TYPE: TEXT/PLAIN
CONTENT: oauth_token={token2}&oauth_token_secret={token2Secret}&member_id={username}
URL que sirve como facilidad para que el proveedor de tokens (SP) nos devuelva la firma correspondiente al request que queremos hacer en base a la clave privada que fué asociada al consumidor (oauth_consumer_key), la cual luego deberá ser anexada al HEADER en el POST correspondiente
-
Request
POST: /{myUtilsApp}/{myRestBind}/oauthUtils/token_signature
HOST: {hostname}:{port}
HEADER: Authorization: OAuth oauth_version="1.0", oauth_nonce="908433656", oauth_signature_method="HMAC-SHA1", oauth_consumer_key="mySPapp", oauth_token="token1", oauth_verifier="260390798", oauth_timestamp="1435322081"
Content-Type: APPLICATION/JSON
BODY: {"url":"http://localhost:8080/col-prestamo-rest/service/oauth/request_token", "method":"POST", "access":"false"}
En OAuth 1.0a es preciso firmar el request compuesto por 3 partes separadas por "&":
REQUEST_TYPE
URL
OAUTH_PARAMS
Por ejemplo
POST&http%3A%2F%2Flocalhost%3A8080%2Fcol-prestamo-rest%2Fservice%2Foauth%2Frequest_token&oauth_callback%3Doob%26oauth_consumer_key%3DmySPapp%26oauth_nonce%3D3400183167%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1435325772%26oauth_version%3D1.0
El parámetro adicional enviado en el BODY llamado "access" se utiliza para determinar si el proceso de firma tiene que usar las claves del consumidor y del token concatenadas. SOLO en el caso de la firma para el "Request token" NO se utilizan claves concatenadas por lo que el valor es "false"
-
Response
TYPE: TEXT/PLAIN
CONTENT: JDjkRPw8c687lZAfMQocpXqqD6c=
URL que sirve como facilidad para dar de alta consumidores
-
Request
POST: /{myUtilsApp}/{myRestBind}/oauthUtils/consumer
HOST: {hostname}:{port}
Content-Type: APPLICATION/JSON
BODY: {"name":"mySPapp"}
-
Response
TYPE: APPLICATION/JSON
CONTENT: {"consumerKey":"82c9240d584a41f28b733ef6ae4a0973","name":"mySPapp","secret":"652b27e1ceb3487f9a207575286830b7"}
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent