search

ging / fiware-idm

OAuth 2.0-based authentication of users and devices, user profile management, Single Sign-On (SSO) and Identity Federation across multiple administration domains.
https://keyrock-fiware.github.io
MIT License
36 stars 81 forks source link

Fiware IDM and PEPproxy in basic PDP never check the permissions #60

Open joansrios opened 5 years ago

joansrios commented 5 years ago

I configured the proxy to show all the debug messages to see why an user without a role can enter to the application, aparently the proxy only checks the token status.

fiware-pep          | 2018-12-05 15:05:44.283  - INFO: IDM-Client - Token in cache, checking timestamp...
fiware-pep          | 2018-12-05 15:05:44.283  - INFO: IDM-Client - dfd82857865d2f41364cc5be90db008e595733ab
fiware-pep          | 2018-12-05 15:05:44.284  - INFO: IDM-Client - Token in cache expired
fiware-pep          | 2018-12-05 15:05:44.285  - INFO: IDM-Client - Checking token with IDM...
fiware-pep          | 2018-12-05 15:05:44.285  - DEBUG: HTTP-Client - Sending  GET  to: http://172.24.1.11:3000/user?access_token=dfd82857865d2f41364cc5be90db008e595733ab
fiware-pep          | 2018-12-05 15:05:44.285  - DEBUG: HTTP-Client -  Headers:  { 'X-Auth-Token': '9cc7bded-fd2e-4dc7-9b09-a46ca8e2a2ae',
fiware-pep          |   Accept: 'application/json' }
fiware-pep          | 2018-12-05 15:05:44.285  - DEBUG: HTTP-Client -  Body:  undefined

The idm returns the user information...

fiware-idm          | Executing (default): SELECT `OauthAccessToken`.`access_token`, `OauthAccessToken`.`access_token` AS `accessToken`, `OauthAccessToken`.`expires` AS `accessTokenExpiresAt`, `OauthAccessToken`.`scope`, `OauthAccessToken`.`valid`, `User`.`id` AS `User.id`, `User`.`username` AS `User.username`, `User`.`email` AS `User.email`, `User`.`gravatar` AS `User.gravatar`, `User`.`extra` AS `User.extra`, `User`.`eidas_id` AS `User.eidas_id`, `Iot`.`id` AS `Iot.id`, `OauthClient`.`id` AS `OauthClient.id`, `OauthClient`.`grant_type` AS `OauthClient.grant_type` FROM `oauth_access_token` AS `OauthAccessToken` LEFT OUTER JOIN `user` AS `User` ON `OauthAccessToken`.`user_id` = `User`.`id` LEFT OUTER JOIN `iot` AS `Iot` ON `OauthAccessToken`.`iot_id` = `Iot`.`id` LEFT OUTER JOIN `oauth_client` AS `OauthClient` ON `OauthAccessToken`.`oauth_client_id` = `OauthClient`.`id` WHERE `OauthAccessToken`.`access_token` = 'dfd82857865d2f41364cc5be90db008e595733ab';
fiware-idm          | Executing (default): SELECT `trusted_oauth_client_id` FROM `trusted_application` AS `trusted_application` WHERE `trusted_application`.`oauth_client_id` = NULL;
fiware-idm          | Executing (default): SELECT `User_Organization`.`id`, `User_Organization`.`role`, `User_Organization`.`user_id`, `User_Organization`.`organization_id`, `Organization`.`id` AS `Organization.id` FROM `user_organization` AS `User_Organization` LEFT OUTER JOIN `organization` AS `Organization` ON `User_Organization`.`organization_id` = `Organization`.`id` WHERE `User_Organization`.`user_id` = '8d5340dd-958e-4935-a230-3995f170ecd1';
fiware-idm          | Executing (default): SELECT `Role_Assignment`.`id`, `Role_Assignment`.`role_organization`, `Role_Assignment`.`role_id`, `Role_Assignment`.`user_id`, `Role_Assignment`.`oauth_client_id`, `Role_Assignment`.`organization_id`, `User`.`id` AS `User.id`, `User`.`username` AS `User.username`, `User`.`email` AS `User.email`, `User`.`gravatar` AS `User.gravatar`, `Role`.`id` AS `Role.id`, `Role`.`name` AS `Role.name`, `Organization`.`id` AS `Organization.id`, `Organization`.`name` AS `Organization.name`, `Organization`.`description` AS `Organization.description`, `Organization`.`website` AS `Organization.website` FROM `role_assignment` AS `Role_Assignment` LEFT OUTER JOIN `user` AS `User` ON `Role_Assignment`.`user_id` = `User`.`id` LEFT OUTER JOIN `role` AS `Role` ON `Role_Assignment`.`role_id` = `Role`.`id` LEFT OUTER JOIN `organization` AS `Organization` ON `Role_Assignment`.`organization_id` = `Organization`.`id` WHERE (((`Role_Assignment`.`organization_id` = '5eebac29-331f-43e8-8f59-0c2ee971da79' AND `Role_Assignment`.`role_organization` = 'member')) OR `Role_Assignment`.`user_id` = '8d5340dd-958e-4935-a230-3995f170ecd1') AND `Role_Assignment`.`oauth_client_id` = 'ef7696c0-8782-4bea-8ea6-04c8885e8999' AND `Role_Assignment`.`role_id` NOT IN ('provider', 'purchaser');
fiware-idm          | GET /user?access_token=dfd82857865d2f41364cc5be90db008e595733ab 201 66.954 ms - 362

and redirect only the request.

fiware-pep          | 2018-12-05 15:05:44.356  - DEBUG: IDM-Client - Token created in application:  ef7696c0-8782-4bea-8ea6-04c8885e8999
fiware-pep          | 2018-12-05 15:05:44.356  - DEBUG: IDM-Client - PEP Proxy application:  ef7696c0-8782-4bea-8ea6-04c8885e8999
fiware-pep          | Refused to set unsafe header "cookie"
fiware-pep          | Refused to set unsafe header "accept-encoding"
fiware-pep          | 2018-12-05 15:05:44.356  - DEBUG: IDM-Client - PEP Proxy trusted_apps:  []
fiware-pep          | 2018-12-05 15:05:44.361  - INFO: Root - Access-token OK. Redirecting to app...
fiware-pep          | 2018-12-05 15:05:44.362  - DEBUG: HTTP-Client - Sending  GET  to: http://172.24.1.7:1026/v2/entities
fiware-pep          | 2018-12-05 15:05:44.362  - DEBUG: HTTP-Client -  Headers:  { 'x-auth-token': 'dfd82857865d2f41364cc5be90db008e595733ab',
fiware-pep          |   'fiware-servicepath': '/nodo',
fiware-pep          |   'cache-control': 'no-cache',
fiware-pep          |   'postman-token': 'c07bbff4-f938-4705-bf85-7d0513cd4777',
fiware-pep          |   'user-agent': 'PostmanRuntime/7.4.0',
fiware-pep          |   accept: '*/*',
fiware-pep          |   host: 'localhost:9091',
fiware-pep          |   cookie: 'session=eyJyZWRpciI6Ii8ifQ==; session.sig=TqcHvLKCvDVxuMk5xVfrKEP-GSQ',
fiware-pep          |   'accept-encoding': 'gzip, deflate',
fiware-pep          |   connection: 'keep-alive',
fiware-pep          |   'X-Nick-Name': '8d5340dd-958e-4935-a230-3995f170ecd1',
fiware-pep          |   'X-Display-Name': '',
fiware-pep          |   'X-Roles': '[{"id":"7ebb17af-85bd-4cb3-8673-2327871d1c69","name":"Desarrollador"}]',
fiware-pep          |   'X-Organizations': '[]',
fiware-pep          |   'X-Eidas-Profile': '{}',
fiware-pep          |   'x-forwarded-for': '::ffff:172.24.1.1' }
fiware-pep          | 2018-12-05 15:05:44.362  - DEBUG: HTTP-Client -  Body:  undefined
fiware-pep          | 2018-12-05 15:05:44.376  - DEBUG: HTTP-Client - Response:  200
fiware-pep          | 2018-12-05 15:05:44.376  - DEBUG: HTTP-Client -  Body:  []
letavia commented 5 years ago

I also struggled with the same condition, what version of idm and pep-proxy are you using? Mine is both with 7.0.2. When I tried to upgrade to 7.5.0 for both with permanent token I got this error message: 

TypeError: Cannot read property 'secret' of undefined
    at pep (/opt/fiware-pep-proxy/controllers/root.js:61:34)
    at Layer.handle [as handle_request] (/opt/fiware-pep-proxy/node_modules/express/lib/router/layer.js:95:5)
    at next (/opt/fiware-pep-proxy/node_modules/express/lib/router/route.js:137:13)
    at next (/opt/fiware-pep-proxy/node_modules/express/lib/router/route.js:131:14)
    at next (/opt/fiware-pep-proxy/node_modules/express/lib/router/route.js:131:14)
    at next (/opt/fiware-pep-proxy/node_modules/express/lib/router/route.js:131:14)
    at next (/opt/fiware-pep-proxy/node_modules/express/lib/router/route.js:131:14)
    at next (/opt/fiware-pep-proxy/node_modules/express/lib/router/route.js:131:14)
    at next (/opt/fiware-pep-proxy/node_modules/express/lib/router/route.js:131:14)
    at Route.dispatch (/opt/fiware-pep-proxy/node_modules/express/lib/router/route.js:112:3)

idm dev team can you please take a look at this? Has this setup worked with version => 7.0.0?

joansrios commented 5 years ago

I'm trying to deploy version 7.5.0 because an older version deployed in a previous project stopped working.

letavia commented 5 years ago

Did you use docker or manual installation? I used docker, first with version 7.0.2 and came across the same issue as yours then with 7.5.0 which gave me the error message. Did you get that error message too? What did you set as the PEP_TOKEN_SECRET parameter? I used permanent token and left it undefined but still the error occurred.

joansrios commented 5 years ago

@letavia i'm using Docker but you are wrong, you need to generate the PEP credentials inside the aplication generated on Keyrock and copy them on the PEP container. The problem is that when i try to test the security making a request with an user without a role, the PEP only checks if the token has not expired.

letavia commented 5 years ago

I know exactly what you mean and am doing the same. The thing is there's a new parameter introduced in 7.5.0 called PEP_TOKEN_SECRET if you look at config.js file and this parameter should not matter if you don't use jwt token for your OAuth2 credentials but even when I am not using jwt I got error related to 'secret' (I assume this has something to do with the jwt secret). With 7.0.2 I didn't come across this issue, but I had the same problem with PEP always allowing access regardless of the roles and permissions.

joansrios commented 5 years ago

@letavia now i'm using the 7.5.0 pep version and now works for me. The latest version of PEP show me your error and then i thought in the jwt secret parameter of the keyrock application. But all works for me when i used this configurations:

# Variables necesarias para el keyrock
DATABASE_HOST=172.24.1.9
IDM_DB_PASS=
IDM_ADMIN_PASS=gruposistemic
IDM_ADMIN_ID=sistemic
IDM_ADMIN_USER=Sistemic
IDM_ADMIN_EMAIL=sistemic@udea.edu.co
IDM_EMAL_ADDRESS=noreply@udea.edu.co
IDM_PDP_LEVEL=basic # basic|advanced  
IDM_AUTHZFORCE_ENABLED= false
IDM_AUTHZFORCE_HOST=172.24.1.15
IDM_AUTHZFORCE_PORT=8080
IDM_SESSION_SECRET=sistemic
IDM_ENCRYPTION_KEY=sistemic
# Variables necesarias para el proxy
PEP_PROXY_IDM_HOST=172.24.1.11
PEP_PROXY_IDM_PORT=3000
PEP_PROXY_IDM_SSL_ENABLED=false
PEP_PROXY_APP_HOST=172.24.1.7
PEP_PROXY_APP_PORT=1026
PEP_PROXY_AUTH_ENABLED=true
PEP_PROXY_PDP=idm # idm|authzforce
PEP_PROXY_AZF_PROTOCOL=http
PEP_PROXY_AZF_HOST=172.24.1.15
PEP_PROXY_AZF_PORT=8080
PEP_PROXY_APP_ID=490a986e-5b79-405a-a5e8-923cad9472ee
PEP_PROXY_USERNAME=pep_proxy_0990d90e-dd24-4ce2-9a48-1ff5735b880d
PEP_PASSWORD=pep_proxy_ece1744d-90ef-4b28-b956-d98509d211c8
PEP_TOKEN_SECRET=8723221e596b71d0

and in the docker-compose file:

# interfaz de configuración y seguridad
  fiware-idm:
    build: fiware-idm
    hostname: fiware-idm
    container_name: fiware-idm
    env_file:
      - .env
    expose:
      - "25"
    ports:
      - "3300:3000"
      - "25:25"
    depends_on:
      - mysql-idm-cygnus
    networks:
      fiware:
        ipv4_address: 172.24.1.11
# proxy
  fiware-pep:
    image: fiware/pep-proxy:7.5.0
    hostname: fiware-pep
    container_name: fiware-pep
    env_file:
      - .env
    expose:
      - "9090"
    ports:
      - "9090:80"
    depends_on:
      - fiware-idm
    networks:
      fiware:
        ipv4_address: 172.24.1.12

for the moment i'm using permanent tokens to the authorizations because works for me...

check later my Sentilo-Fiware repository to see an example

letavia commented 5 years ago

Hi, I finally managed to do it with 7.5.0. With 7.0.2 apparently there is an error in the config.js that you have to fix after you install it. With 7.5.0 the error I used to have vanished (maybe they fixed it!) and it seems to be working fine. I am using also bearer permanent token since jwt token does not work with authzforce. The PEP_TOKEN_SECRET env variable is useless even if you are using jwt token.

A bit OOT: did you ever try authorization with xacml? I was wondering how we can put the fiware-service and fiware-servicepath header in the xacml policy.