Role assignment and user authorization

[ddrenjanac]

Hi,

we have a problem with a role assignment and user authorization in keystone. Following is our use case:

We have two users in keystone, default one named idm and a user we created named test0. User idm registered an application which provided oauth2 credentials to oauth2 example client as well as pep proxy credentials to pep proxy. Moreover, user test0 is added as authorized user in the application and it is assigned two roles. Those roles can be called x and y since they are created only for this application.

1. first problem is when the user test0 utilizes oauth2 access token (successfully obtained using oauth2 example client) to call a resource behind pep proxy. In that case, the request is intercepted by pep proxy and it is forwarded to the IDM (following call):

GET /v3/access-tokens/ZYCkPdz3D78DGei79wpfiXtciiXZgT

IDM returns user info, but it does not return roles assigned to the user test0. However, I can see in the keystone database using sqlite browser that there is an entry in the table role_user_fiware denoting that user test0 has roles x and y.

It could be that I am missing something, but could you explain this behavior?

1. second problem is when user test0 logs in the portal with corresponding credentials, under the My Applications --> Authorized there is no entry denoting that user0 is authorized in the above application.

Is this problem in some sense is related to the first problem?

Best regards, Domagoj

[federicofdez]

Hi @ddrenjanac,

After looking into the second problem you're reporting, turns out that there is something wrong with the IDs of fiware roles. They should be just provider and purchaser, instead of provider_role and purchaser_role, which are the values that the Keystone initial-data extension used to assign.

We just fixed this in https://github.com/ging/keystone/commit/01fb769e1245db25a2dbf948999147b1ca442861 and https://github.com/ging/horizon/commit/6ab0e7d2ee1f17048d0ec54d2bc749eceab1107b. Basically, you need to do the following:

1. Update FIWARE_PURCHASER_ROLE_ID and FIWARE_PROVIDER_ROLE_ID in your local_settings.py file (the one placed in horizon/openstack_dashboard/local), as you can see in https://github.com/ging/horizon/commit/6ab0e7d2ee1f17048d0ec54d2bc749eceab1107b.
2. Update your Keystone database, by either running an UPDATE query to replace the IDs or (if you can afford so) just drop your database and re-create it again (the fix in https://github.com/ging/keystone/commit/01fb769e1245db25a2dbf948999147b1ca442861 should correct the IDs).

Regarding the first problem you're reporting, we'll perform several tests in the following days to try to figure out what's going wrong, and come back to you ASAP.

Best regards, Federico

[bekatom]

@FedericoFdez Do you know is this last changes updated on Fiware Cloud portal ? I mean in ready instance of keyrock-R5.1.0 . As I know this image was created at Feb-16 .

[federicofdez]

Hi @btomashvili,

We're planning to include these and some other fixes in a new release (5.1.1), which will come out within a few days. We'll update the instance in the Cloud Portal as soon as this happens.

[federicofdez]

Hi @ddrenjanac,

Regarding the first issue you reported, I understand that you are expecting a response like this one (as explained in the docs):

{
  id: 1,
  displayName: "Demo user",
  email: "demo@fiware.org",
  roles: [
    {
      id: 15,
      name: "Manager"
    },
    {
      id: 7
      name: "Ticket manager"
    }
  ],
  organizations: [
    {
       id: 12,
       name: "Universidad Politecnica de Madrid",
       roles: [
         {
           id: 14,
           name: "Admin"
         }
      ]
    }
  ]
}

If you check the link in the docs I took this response from, you will find that the endpoint is not exactly the one you seem to be using, but GET /user?access_token=ZYCkPdz3D78DGei79wpfiXtciiXZgT.

My recommendation is that you check your configuration to see if the right endpoint is used. Just come back to me if you still have problems after fixing this.

This is the process I followed to make sure that roles are retrieved right, and had no trouble:

1. I registered a new Application in my local Keyrock instance.
2. I set up an example OAuth app (I used this one) with the credentials I got from Keyrock.
3. I checked whether the User object the app retrieves contains the assigned roles (and it does).

Best regards, Federico

[bekatom]

@FedericoFdez Is any news regard updating Fiware cloud instance ?

[ddrenjanac]

Hi @FedericoFdez

thank you for provided help. Unfortunately I did not have success in solving those two problems:

1 - problem - the GET request I posted is not generated by me. Indeed, it it the request generated by PEP enabler when asking IDM to check received access token. Does it mean that I have to change some code in PEP? (So far I already had to change something there regarding XACML parsing).

Can you please post full URL for the request you issued against keystone to get the roles?

2 - problem - I have updated local_settings.py file and it look like this:

FIWARE_PURCHASER_ROLE_ID = 'purchaser' FIWARE_PROVIDER_ROLE_IS = 'provider'

I have also updated following tables accordingly: role_fiware, role_permission_fiware, role_user_fiwware, and role_organization_fiware. After that I restarted horizon and keystone, but the above described problem still persists.

I have one more question, is there a table in DB where an application data are stored? I see that an application_id occurs in some tables.

Best regards, Domagoj

[federicofdez]

Hi @ddrenjanac

What version of Keyrock are you using? I just followed this process in a 5.1.1 Keyrock and had actually no trouble:

1. I created two users: user0 and user1.
2. I registered an app as user0, and created two roles: roleX and roleY.
3. I configured the app (I used this one again) with the OAuth2 credentials that Keyrock provides.
4. I authorized user1 in the app and assigned it two roles: roleX and roleY.
5. I accessed the example app and logged in as user1, and the app showed me an access token. In my case this token was n0aaNmJROxcLaNiQSPuXZQydY6tkGQ.

6. I made the following request to Keystone, just as the PEP-Proxy would do:

   curl -H "X-Auth-Token: ADMIN" http://localhost:5000/v3/access-tokens/n0aaNmJROxcLaNiQSPuXZQydY6tkGQ

   and got the following response:

   {
   "organizations": [],
   "displayName": "user1",
   "roles": [
    {
      "name": "roleY",
      "id": "e2f0ee1930f740ed9e6338f3d900b5a3"
    },
    {
      "name": "roleX",
      "id": "6ae6be994e50423788bb3950fbc9656a"
    }
   ],
   "app_id": "8e241703cd2844ecb81fe1b6b19a0f31",
   "email": "user1@test.com",
   "id": "user1"
   }

As you can see, the response contains the roles I just assigned. Are you having trouble when following these exact steps?

Best regards,

[ddrenjanac]

Hi @FedericoFdez

thank you for fast reply! Yes, that is the behavior I am expecting from the system.

1) I am not sure which keyrock version do I have. About a month ago I have cloned from github horizon and keystone as separate projects and thus I am not sure where to check which keyrock version do I have?

2) After I create a new user, I receive an activation email on an email server I set up in horizon (local_settings.py). Unfortunately, the activation email usually does not work and I tried to activate the new user by updating the database, in particular table user field enabled (set to 1). I am not sure whether this is sufficient since the new user can not login (Message: You are not authorized for any projects). I do not remember how I did that before since I already have any user in addition to idm user.

UPDATE:

• it seems that the complete user activation is done after updating table project and setting the field enabled to 1.
• After following your steps I got the same json response (with the roles I created). I tested it with PEP as well, and seems that PEP also got those roles!

Now, the only thing left for having a complete IDM is to figure out how PDP evaluates XACML policies created in Horizon.

Thank you for help.

Best regards, Domagoj

[federicofdez]

Hi @ddrenjanac,

So glad to hear that it's working! I guess the problem was related to the user account not being activated.

When you follow the activation link you receive in the activation email, we enable both the user, its default project and its cloud project, as you just figured out. The easiest way is of course to follow the link in the email, so I recommend that you set it up correctly. Just have a look at the docs if you're in a production environment.

If you're in a development environment, you can simply use the Django console email backend (configured by default), which will output the email to the Horizon console. All you need to do is head towards the console and look for a link like this one in the email content:

http://localhost:8000/activate/?activation_key=f95bd139c84c4d6fac99e82f96cf6a99&user=user_name

where user_name will be the one you chose in the registration process. Just follow this link from your browser and the account will be activated.

Best regards, Federico

[federicofdez]

@btomashvili

I'm afraid that you will have to wait for the next FIWARE release (5.2.0), which is planned to be coming out in a few weeks. In the meantime, you can use the 5.1.0 image and just git pull the new changes.

[ddrenjanac]

Hi @FedericoFdez

after successfully solving the role assignment issues, now I have a problem with a user authorization. First, I will briefly describe my test use case and then I will provide necessary configuration parameters as well as XACML outputs from involved components.

I have created a dummy REST web service that exposes two GET services under the following resources: /REST_PDP/v1/deposit and /REST_PDP/v1/withdraw. Both services return just a string equals to their names.

There should be two different roles to access the provided REST services: (1) Manager who is able to access both service, and (2) Executor able to access only deposit service.

From before, I have two users: user0 and user1. Using Horizon I have logged in with admin, i.e., user idm, who already has a registered application which provides credentials for a dummy oauth client and pep proxy as well. In the registered application I have created two roles, i.e., Manager and Executor. Additionally, I have created two permissions where both pertain to the GET method but have different resources. One pertains to the deposit service and other to withdraw service. Moreover, I have authorized two users, i.e., user0 and user1, to use this application and assigned role Manager to user0 and role Executor to user1. Following is XACML that Horizon generated and wrote in PAP.

<PolicySet xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" PolicySetId="cdcbdf2e94524524852aea1f6b16d1c4" Version="1.0"  PolicyCombiningAlgId="urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-unless-permit">
    <Description>Policy Set for application cdcbdf2e94524524852aea1f6b16d1c4</Description>
    <Target />

        <Policy PolicyId="" Version="1.0" RuleCombiningAlgId="urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-unless-permit">
  <Description>Role afb6f40c24a64f499a2ad1854425a372 from application cdcbdf2e94524524852aea1f6b16d1c4</Description>
  <Target>
    <AnyOf>
      <AllOf>
        <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
          <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">cdcbdf2e94524524852aea1f6b16d1c4</AttributeValue>
          <AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
              AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http://www.w3.org/2001/XMLSchema#string"
              MustBePresent="true" />
        </Match>
      </AllOf>
    </AnyOf>
  </Target>

      <Rule RuleId="2521dcd5be12443e8579e4f16b909a52" Effect="Permit">
  <Description>BUCP_deposit</Description>
  <Target>
    <AnyOf>
      <AllOf>
        <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
          <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">REST_PDP/v1/deposit</AttributeValue>
          <AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
              AttributeId="urn:thales:xacml:2.0:resource:sub-resource-id" DataType="http://www.w3.org/2001/XMLSchema#string"
              MustBePresent="true" />
        </Match>
      </AllOf>
    </AnyOf>
    <AnyOf>
      <AllOf>
        <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
          <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">GET</AttributeValue>
          <AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"
              AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string"
              MustBePresent="true" />
        </Match>
      </AllOf>
    </AnyOf>
  </Target>
  <Condition>
    <Apply FunctionId="urn:oasis:names:tc:xacml:3.0:function:any-of">
      <Function FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal" />
      <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">afb6f40c24a64f499a2ad1854425a372</AttributeValue>
      <AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role"
          DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"
          Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" />
    </Apply>
  </Condition>
</Rule>

</Policy>

<Policy PolicyId="" Version="1.0" RuleCombiningAlgId="urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-unless-permit">
  <Description>Role c2af9116bbcc4dd583d937d62b5c9669 from application cdcbdf2e94524524852aea1f6b16d1c4</Description>
  <Target>
    <AnyOf>
      <AllOf>
        <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
          <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">cdcbdf2e94524524852aea1f6b16d1c4</AttributeValue>
          <AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
              AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http://www.w3.org/2001/XMLSchema#string"
              MustBePresent="true" />
        </Match>
      </AllOf>
    </AnyOf>
  </Target>

  <Rule RuleId="7c9da4e3e142422b94aa3599e29a1131" Effect="Permit">
  <Description>BUCP_withdraw</Description>
  <Target>
    <AnyOf>
      <AllOf>
        <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
          <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">REST_PDP/v1/withdraw</AttributeValue>
          <AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
              AttributeId="urn:thales:xacml:2.0:resource:sub-resource-id" DataType="http://www.w3.org/2001/XMLSchema#string"
              MustBePresent="true" />
        </Match>
      </AllOf>
    </AnyOf>
    <AnyOf>
      <AllOf>
        <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
          <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">GET</AttributeValue>
          <AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"
              AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string"
              MustBePresent="true" />
        </Match>
      </AllOf>
    </AnyOf>
  </Target>
  <Condition>
    <Apply FunctionId="urn:oasis:names:tc:xacml:3.0:function:any-of">
      <Function FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal" />
      <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">c2af9116bbcc4dd583d937d62b5c9669</AttributeValue>
      <AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role"
          DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"
          Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" />
    </Apply>
  </Condition>
</Rule>

      <Rule RuleId="2521dcd5be12443e8579e4f16b909a52" Effect="Permit">
  <Description>BUCP_deposit</Description>
  <Target>
    <AnyOf>
      <AllOf>
        <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
          <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">REST_PDP/v1/deposit</AttributeValue>
          <AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
              AttributeId="urn:thales:xacml:2.0:resource:sub-resource-id" DataType="http://www.w3.org/2001/XMLSchema#string"
              MustBePresent="true" />
        </Match>
      </AllOf>
    </AnyOf>
    <AnyOf>
      <AllOf>
        <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
          <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">GET</AttributeValue>
          <AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"
              AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string"
              MustBePresent="true" />
        </Match>
      </AllOf>
    </AnyOf>
  </Target>
  <Condition>
    <Apply FunctionId="urn:oasis:names:tc:xacml:3.0:function:any-of">
      <Function FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal" />
      <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">c2af9116bbcc4dd583d937d62b5c9669</AttributeValue>
      <AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role"
          DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"
          Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" />
    </Apply>
  </Condition>
</Rule>
</Policy>

</PolicySet>

Here are two policies and one has one rule and the other two rules. It seems that each policy corresponds to the permissions assigned to one role.

User1 utilizes dummy oauth client to get an access token from IDM. After obtaining the access token, following curl call is issued:

curl --header "X-Auth-Token:IqTRfFoAzAobdTknMin8RFMPs7WDL0" http://localhost:80/REST_PDP/v1/withdraw

The call is intercepted by PEP which logs following:

2016-03-10 15:06:19.643  - INFO: IDM-Client - Checking token with IDM...
2016-03-10 15:06:19.676  - INFO: AZF-Client - Checking auth with AZF...
2016-03-10 15:06:19.676  - INFO: AZF-Client - Checking authorization to roles [ 'afb6f40c24a64f499a2ad1854425a372' ] to do  GET  on resource  REST_PDP/v1/withdraw and app  cdcbdf2e94524524852aea1f6b16d1c4

Role with id 'afb6f40c24a64f499a2ad1854425a372' corresponds to the role Executor.

Following is XACML request that PEP sent to PDP:

<?xml version="1.0" encoding="UTF-8"?>
<Request xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" CombinedDecision="false" ReturnPolicyIdList="false">
   <Attributes Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
      <Attribute AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" IncludeInResult="false">
         <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">afb6f40c24a64f499a2ad1854425a372</AttributeValue>
      </Attribute>
   </Attributes>
   <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
      <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" IncludeInResult="false">
         <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">cdcbdf2e94524524852aea1f6b16d1c4</AttributeValue>
      </Attribute>
      <Attribute AttributeId="urn:thales:xacml:2.0:resource:sub-resource-id" IncludeInResult="false">
         <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">REST_PDP/v1/withdraw</AttributeValue>
      </Attribute>
   </Attributes>
   <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">
      <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" IncludeInResult="false">
         <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">GET</AttributeValue>
      </Attribute>
   </Attributes>
   <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment" />
</Request>

Although the role Executor does not have permission to call execute REST service, PDP returns permit.

It is worth to notice that both, Horizon and PEP, are pointing out to the same domain in PDP.

Horizon configuration:

ACCESS_CONTROL_URL = 'http://localhost:8080/authzforce-ce/domains/8eRMIdDKEeWH-gAMKfwfVg/pap/policies'
ACCESS_CONTROL_MAGIC_KEY = 'undefined'

PEP configuration:

config.azf = {
    enabled: true,
    host: '127.0.0.1',
    port: 8080,
    path: '/authzforce-ce/domains/8eRMIdDKEeWH-gAMKfwfVg/pdp',
    custom_policy: undefined // use undefined to default policy checks (HTTP verb + path).
};

Can anyone help me with this?

Thanks!

Best regards, Domagoj

[federicofdez]

Answered in https://github.com/ging/fiware-idm/issues/49.