IBM Security Verify

Although there are some duplication from USC cookbook and MMFA cookbook both written by Jon Harry, there are some specific thing related to USC that I would like to have further explanation:

• When specifying the URL, which URL should be used? In the cookbook it is used http://localhost/scim.
  • The URL is meant to be delivered to the AAC runtime, or reverse proxy?
    • If it is the reverse proxy, then there must be defined a scim junction, and open http port. Shouldn't this reverse proxy or the junction be restricted to ISAM internal use only, and consequently not available to other users through the reverse proxy? In fact, the /scim junction has the localhost as the backend server.
      • I already user the reverse proxy (not localhost) with the /scim function and seems to work, but it is inefficient, so there must be a better way of doing this.
    • If it is the AAC runtime, then localhost or policy server host should used as URL?
    • If it is the AAC runtime, as the /scim junction backend server for the reverse proxy is localhost, should this URL be the same? Then what is /scim doing there?

• When creating a Server Connection for SCIM Web Service, we are supposed to add easuser and its password. Why this user and not Scim Administrator's password? To have permission to make changes in scim we must use a user that belongs to the scim admin Group!
• When Configuring Google reCAPTCHA site key, we must use a Domain. If we have ISVA configured in the intranet, and ISAM has a local domain (e.g. internal.example.com) not visible from internet, what should we use on the Domain parameter?
• Regarding the stepup resource, if we provide /scim apis from ISVA, where we have PUT /Users/{id} as an endpoint shouldn't we we apply the stepup policy to unauthenticated users to the PUT /scim/Users, because if they are authenticated, they should only be able to change their own data, since we already identified the user.
  • If we were to put a policy on the resource, because it is a Rest API, how can we restrict the stepup only to PUT or POST methods?

------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994
------------------------------

Hi Joao,

> When specifying the URL, which URL should be used? In the cookbook it is used http://localhost/scim.
> The URL is meant to be delivered to the AAC runtime, or reverse proxy?

If you're creating a "Server Connection" for (privileged) access to SCIM for User Self Care mechanisms, then this should connect directly to the Runtime.
Effectively the Runtime is connecting to itself so the use of http://localhost/scim is correct.  It is not going via the Reverse Proxy.

If you're creating an access point to the SCIM function for a 3rd party application or for unprivileged access for end users then this should be via the Reverse Proxy.

> If it is the AAC runtime, then localhost or policy server host should used as URL?

Unless you have changed the interface that the runtime listens on, use of localhost is correct.  This is a loopback connection.

> If it is the AAC runtime, as the /scim junction backend server for the reverse proxy is localhost, should this URL be the same? Then what is /scim doing there?

The context-root for the SCIM function in the runtime is /scim so all URLs start with this.  When defining the /scim junction in the Reverse Proxy it is a transparent-path junction so the /scim part of the path is passed on to the runtime.

> When creating a Server Connection for SCIM Web Service, we are supposed to add easuser and its password. Why this user and not Scim Administrator's password? To have permission to make changes in scim we must use a user that belongs to the scim admin Group!

The easuser is (by default) a member of the scimAdmin group defined in the AAC user registry.  If you want to create a new user (or group if you have changed the admin group name in SCIM config) then that's fine.  Using easuser is just the easiest option because it already exists in a new system.

> When Configuring Google reCAPTCHA site key, we must use a Domain. If we have ISVA configured in the intranet, and ISAM has a local domain (e.g. internal.example.com) not visible from internet, what should we use on the Domain parameter?

It is whatever domain the browser is accessing to reach the page showing the reCAPTCHA; it doesn't have to be visible from internet - it's used by Google code that runs in your browser (and probably for CSS protection too).

> Regarding the stepup resource, if we provide /scim apis from ISVA, where we have PUT /Users/{id} as an endpoint shouldn't we we apply the stepup policy to unauthenticated users to the PUT /scim/Users, because if they are authenticated, they should only be able to change their own data, since we already identified the user.
If we were to put a policy on the resource, because it is a Rest API, how can we restrict the stepup only to PUT or POST methods?

If you publish the /scim APIs via the Reverse Proxy, the junction must be configured to send the iv-user and iv-group headers and the SCIM configuration must have authorization enabled.  The SCIM function will know (from iv-group header) that the end user connecting is not an administrator and so will only allow them to view and update their own information.  You should not configure the system in such a way that all users can view/change other users.

If you want to limit access to different HTTP methods this is possible via ACL.  It's even possible to remap which permission bits apply to which methods if you want more fine-grained control.  This isn't step-up though.  You can't specify step-up per method using POPs.  I think you would have to use AAC context-based access for this.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------

Original Message:
Sent: Tue April 20, 2021 12:47 PM
From: Joao Goncalves
Subject: Analysing User Self Care in ISAM Cookbook

Although there are some duplication from USC cookbook and MMFA cookbook both written by Jon Harry, there are some specific thing related to USC that I would like to have further explanation:

• When specifying the URL, which URL should be used? In the cookbook it is used http://localhost/scim.
  • The URL is meant to be delivered to the AAC runtime, or reverse proxy?
    • If it is the reverse proxy, then there must be defined a scim junction, and open http port. Shouldn't this reverse proxy or the junction be restricted to ISAM internal use only, and consequently not available to other users through the reverse proxy? In fact, the /scim junction has the localhost as the backend server.
      • I already user the reverse proxy (not localhost) with the /scim function and seems to work, but it is inefficient, so there must be a better way of doing this.
    • If it is the AAC runtime, then localhost or policy server host should used as URL?
    • If it is the AAC runtime, as the /scim junction backend server for the reverse proxy is localhost, should this URL be the same? Then what is /scim doing there?

• When creating a Server Connection for SCIM Web Service, we are supposed to add easuser and its password. Why this user and not Scim Administrator's password? To have permission to make changes in scim we must use a user that belongs to the scim admin Group!
• When Configuring Google reCAPTCHA site key, we must use a Domain. If we have ISVA configured in the intranet, and ISAM has a local domain (e.g. internal.example.com) not visible from internet, what should we use on the Domain parameter?
• Regarding the stepup resource, if we provide /scim apis from ISVA, where we have PUT /Users/{id} as an endpoint shouldn't we we apply the stepup policy to unauthenticated users to the PUT /scim/Users, because if they are authenticated, they should only be able to change their own data, since we already identified the user.
  • If we were to put a policy on the resource, because it is a Rest API, how can we restrict the stepup only to PUT or POST methods?

------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994
------------------------------

Just one additional question that your answer was not clear.
The scim Administration Group, is defined in a federated repository. Its users are basic users.

easuser belongs to the AAC runtime registry. How can I configure the SCIM Web Service URL, username and password, for a basic user to access localhost/scim?

------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994
------------------------------

Original Message:
Sent: Wed April 21, 2021 06:06 AM
From: Jon Harry
Subject: Analysing User Self Care in ISAM Cookbook

Hi Joao,

> When specifying the URL, which URL should be used? In the cookbook it is used http://localhost/scim.
> The URL is meant to be delivered to the AAC runtime, or reverse proxy?

If you're creating a "Server Connection" for (privileged) access to SCIM for User Self Care mechanisms, then this should connect directly to the Runtime.
Effectively the Runtime is connecting to itself so the use of http://localhost/scim is correct.  It is not going via the Reverse Proxy.

If you're creating an access point to the SCIM function for a 3rd party application or for unprivileged access for end users then this should be via the Reverse Proxy.

> If it is the AAC runtime, then localhost or policy server host should used as URL?

Unless you have changed the interface that the runtime listens on, use of localhost is correct.  This is a loopback connection.

> If it is the AAC runtime, as the /scim junction backend server for the reverse proxy is localhost, should this URL be the same? Then what is /scim doing there?

The context-root for the SCIM function in the runtime is /scim so all URLs start with this.  When defining the /scim junction in the Reverse Proxy it is a transparent-path junction so the /scim part of the path is passed on to the runtime.

> When creating a Server Connection for SCIM Web Service, we are supposed to add easuser and its password. Why this user and not Scim Administrator's password? To have permission to make changes in scim we must use a user that belongs to the scim admin Group!

The easuser is (by default) a member of the scimAdmin group defined in the AAC user registry.  If you want to create a new user (or group if you have changed the admin group name in SCIM config) then that's fine.  Using easuser is just the easiest option because it already exists in a new system.

> When Configuring Google reCAPTCHA site key, we must use a Domain. If we have ISVA configured in the intranet, and ISAM has a local domain (e.g. internal.example.com) not visible from internet, what should we use on the Domain parameter?

It is whatever domain the browser is accessing to reach the page showing the reCAPTCHA; it doesn't have to be visible from internet - it's used by Google code that runs in your browser (and probably for CSS protection too).

> Regarding the stepup resource, if we provide /scim apis from ISVA, where we have PUT /Users/{id} as an endpoint shouldn't we we apply the stepup policy to unauthenticated users to the PUT /scim/Users, because if they are authenticated, they should only be able to change their own data, since we already identified the user.
If we were to put a policy on the resource, because it is a Rest API, how can we restrict the stepup only to PUT or POST methods?

If you publish the /scim APIs via the Reverse Proxy, the junction must be configured to send the iv-user and iv-group headers and the SCIM configuration must have authorization enabled.  The SCIM function will know (from iv-group header) that the end user connecting is not an administrator and so will only allow them to view and update their own information.  You should not configure the system in such a way that all users can view/change other users.

If you want to limit access to different HTTP methods this is possible via ACL.  It's even possible to remap which permission bits apply to which methods if you want more fine-grained control.  This isn't step-up though.  You can't specify step-up per method using POPs.  I think you would have to use AAC context-based access for this.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM

Original Message:
Sent: Tue April 20, 2021 12:47 PM
From: Joao Goncalves
Subject: Analysing User Self Care in ISAM Cookbook

Although there are some duplication from USC cookbook and MMFA cookbook both written by Jon Harry, there are some specific thing related to USC that I would like to have further explanation:

• When specifying the URL, which URL should be used? In the cookbook it is used http://localhost/scim.
  • The URL is meant to be delivered to the AAC runtime, or reverse proxy?
    • If it is the reverse proxy, then there must be defined a scim junction, and open http port. Shouldn't this reverse proxy or the junction be restricted to ISAM internal use only, and consequently not available to other users through the reverse proxy? In fact, the /scim junction has the localhost as the backend server.
      • I already user the reverse proxy (not localhost) with the /scim function and seems to work, but it is inefficient, so there must be a better way of doing this.
    • If it is the AAC runtime, then localhost or policy server host should used as URL?
    • If it is the AAC runtime, as the /scim junction backend server for the reverse proxy is localhost, should this URL be the same? Then what is /scim doing there?

• When creating a Server Connection for SCIM Web Service, we are supposed to add easuser and its password. Why this user and not Scim Administrator's password? To have permission to make changes in scim we must use a user that belongs to the scim admin Group!
• When Configuring Google reCAPTCHA site key, we must use a Domain. If we have ISVA configured in the intranet, and ISAM has a local domain (e.g. internal.example.com) not visible from internet, what should we use on the Domain parameter?
• Regarding the stepup resource, if we provide /scim apis from ISVA, where we have PUT /Users/{id} as an endpoint shouldn't we we apply the stepup policy to unauthenticated users to the PUT /scim/Users, because if they are authenticated, they should only be able to change their own data, since we already identified the user.
  • If we were to put a policy on the resource, because it is a Rest API, how can we restrict the stepup only to PUT or POST methods?

------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994
------------------------------

Hi Joao,

There is some confusion here because you only configure a single "Admin Group" in SCIM configuration but it can be applied in two different ways.

The SCIM app only does its internal authentication against the AAC runtime registry.  This is for the username passed in Basic Authentication header.

For internal (privileged) connection to the SCIM app, this BA header is populated in the SCIM Server Connection.  The user needs to be defined in the AAC runtime registry and needs to be in group with name that matches the "Admin Group" in SCIM configuration.

For external connection to the SCIM app (via Reverse Proxy), the BA header is populated in the junction configuration.  The user needs to be defined in the AAC runtime registry but group membership is not important.   In this case the BA header is just establishing trust between Reverse Proxy and SCIM app.
With this trust established, the SCIM app reads the *real* user and group memberships from iv-user and iv-group HTTP headers.

If a group in iv-groups header matches the "Admin Group" defined in SCIM config then admin permissions are granted. All accounts (and groups) can be viewed and modified.

If the "Admin Group" is not found then the user is non-admin and they can only view and modify their own account.

I hope that helps to explain.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------

Original Message:
Sent: Wed April 21, 2021 06:22 AM
From: Joao Goncalves
Subject: Analysing User Self Care in ISAM Cookbook

Just one additional question that your answer was not clear.
The scim Administration Group, is defined in a federated repository. Its users are basic users.

easuser belongs to the AAC runtime registry. How can I configure the SCIM Web Service URL, username and password, for a basic user to access localhost/scim?

------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994

Original Message:
Sent: Wed April 21, 2021 06:06 AM
From: Jon Harry
Subject: Analysing User Self Care in ISAM Cookbook

Hi Joao,

> When specifying the URL, which URL should be used? In the cookbook it is used http://localhost/scim.
> The URL is meant to be delivered to the AAC runtime, or reverse proxy?

If you're creating a "Server Connection" for (privileged) access to SCIM for User Self Care mechanisms, then this should connect directly to the Runtime.
Effectively the Runtime is connecting to itself so the use of http://localhost/scim is correct.  It is not going via the Reverse Proxy.

If you're creating an access point to the SCIM function for a 3rd party application or for unprivileged access for end users then this should be via the Reverse Proxy.

> If it is the AAC runtime, then localhost or policy server host should used as URL?

Unless you have changed the interface that the runtime listens on, use of localhost is correct.  This is a loopback connection.

> If it is the AAC runtime, as the /scim junction backend server for the reverse proxy is localhost, should this URL be the same? Then what is /scim doing there?

The context-root for the SCIM function in the runtime is /scim so all URLs start with this.  When defining the /scim junction in the Reverse Proxy it is a transparent-path junction so the /scim part of the path is passed on to the runtime.

> When creating a Server Connection for SCIM Web Service, we are supposed to add easuser and its password. Why this user and not Scim Administrator's password? To have permission to make changes in scim we must use a user that belongs to the scim admin Group!

The easuser is (by default) a member of the scimAdmin group defined in the AAC user registry.  If you want to create a new user (or group if you have changed the admin group name in SCIM config) then that's fine.  Using easuser is just the easiest option because it already exists in a new system.

> When Configuring Google reCAPTCHA site key, we must use a Domain. If we have ISVA configured in the intranet, and ISAM has a local domain (e.g. internal.example.com) not visible from internet, what should we use on the Domain parameter?

It is whatever domain the browser is accessing to reach the page showing the reCAPTCHA; it doesn't have to be visible from internet - it's used by Google code that runs in your browser (and probably for CSS protection too).

> Regarding the stepup resource, if we provide /scim apis from ISVA, where we have PUT /Users/{id} as an endpoint shouldn't we we apply the stepup policy to unauthenticated users to the PUT /scim/Users, because if they are authenticated, they should only be able to change their own data, since we already identified the user.
If we were to put a policy on the resource, because it is a Rest API, how can we restrict the stepup only to PUT or POST methods?

If you publish the /scim APIs via the Reverse Proxy, the junction must be configured to send the iv-user and iv-group headers and the SCIM configuration must have authorization enabled.  The SCIM function will know (from iv-group header) that the end user connecting is not an administrator and so will only allow them to view and update their own information.  You should not configure the system in such a way that all users can view/change other users.

If you want to limit access to different HTTP methods this is possible via ACL.  It's even possible to remap which permission bits apply to which methods if you want more fine-grained control.  This isn't step-up though.  You can't specify step-up per method using POPs.  I think you would have to use AAC context-based access for this.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM

Original Message:
Sent: Tue April 20, 2021 12:47 PM
From: Joao Goncalves
Subject: Analysing User Self Care in ISAM Cookbook

Although there are some duplication from USC cookbook and MMFA cookbook both written by Jon Harry, there are some specific thing related to USC that I would like to have further explanation:

• When specifying the URL, which URL should be used? In the cookbook it is used http://localhost/scim.
  • The URL is meant to be delivered to the AAC runtime, or reverse proxy?
    • If it is the reverse proxy, then there must be defined a scim junction, and open http port. Shouldn't this reverse proxy or the junction be restricted to ISAM internal use only, and consequently not available to other users through the reverse proxy? In fact, the /scim junction has the localhost as the backend server.
      • I already user the reverse proxy (not localhost) with the /scim function and seems to work, but it is inefficient, so there must be a better way of doing this.
    • If it is the AAC runtime, then localhost or policy server host should used as URL?
    • If it is the AAC runtime, as the /scim junction backend server for the reverse proxy is localhost, should this URL be the same? Then what is /scim doing there?

• When creating a Server Connection for SCIM Web Service, we are supposed to add easuser and its password. Why this user and not Scim Administrator's password? To have permission to make changes in scim we must use a user that belongs to the scim admin Group!
• When Configuring Google reCAPTCHA site key, we must use a Domain. If we have ISVA configured in the intranet, and ISAM has a local domain (e.g. internal.example.com) not visible from internet, what should we use on the Domain parameter?
• Regarding the stepup resource, if we provide /scim apis from ISVA, where we have PUT /Users/{id} as an endpoint shouldn't we we apply the stepup policy to unauthenticated users to the PUT /scim/Users, because if they are authenticated, they should only be able to change their own data, since we already identified the user.
  • If we were to put a policy on the resource, because it is a Rest API, how can we restrict the stepup only to PUT or POST methods?

------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994
------------------------------

Ok. Let me try to explain what I am experiencing.
In the SCIM configuration, the administration Group  is scimAdmins
scimAdmins is a group defined in a federated ldap server, where there is a basic user named scimadmin that belong to this group.
This user can access successfully scim apis through the reverse proxy where the /scim junction is defined.

Now, I need to implement USC password Reset.
I will need to define a Server connection of type Web Service (I called it localscim).
In this Service connection, I am using the URL: https://localhost/scim and username easuser

When an unauthenticated user tries to reset his password, this connection is used. From what I see in the logs, it tries to use easuser to access /scim endpoints and the system is complaining because easuser does not belong to the group scimAdmins.

How do I specify the user scimadmin to be able do the /scim/Users?filter=email?

If I understand you correctly, I must also have a group in AAC registry with the same name as it was defined in the federated registry (e.g. scimAdmins), and I must have a user (easuser or scimadmin) in the AAC registry that must be a member of AAC registry group scimAdmins!?@!?

------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994
------------------------------

Original Message:
Sent: Wed April 21, 2021 06:54 AM
From: Jon Harry
Subject: Analysing User Self Care in ISAM Cookbook

Hi Joao,

There is some confusion here because you only configure a single "Admin Group" in SCIM configuration but it can be applied in two different ways.

The SCIM app only does its internal authentication against the AAC runtime registry.  This is for the username passed in Basic Authentication header.

For internal (privileged) connection to the SCIM app, this BA header is populated in the SCIM Server Connection.  The user needs to be defined in the AAC runtime registry and needs to be in group with name that matches the "Admin Group" in SCIM configuration.

For external connection to the SCIM app (via Reverse Proxy), the BA header is populated in the junction configuration.  The user needs to be defined in the AAC runtime registry but group membership is not important.   In this case the BA header is just establishing trust between Reverse Proxy and SCIM app.
With this trust established, the SCIM app reads the *real* user and group memberships from iv-user and iv-group HTTP headers.

If a group in iv-groups header matches the "Admin Group" defined in SCIM config then admin permissions are granted. All accounts (and groups) can be viewed and modified.

If the "Admin Group" is not found then the user is non-admin and they can only view and modify their own account.

I hope that helps to explain.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM

Original Message:
Sent: Wed April 21, 2021 06:22 AM
From: Joao Goncalves
Subject: Analysing User Self Care in ISAM Cookbook

Just one additional question that your answer was not clear.
The scim Administration Group, is defined in a federated repository. Its users are basic users.

easuser belongs to the AAC runtime registry. How can I configure the SCIM Web Service URL, username and password, for a basic user to access localhost/scim?

------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994

Original Message:
Sent: Wed April 21, 2021 06:06 AM
From: Jon Harry
Subject: Analysing User Self Care in ISAM Cookbook

Hi Joao,

> When specifying the URL, which URL should be used? In the cookbook it is used http://localhost/scim.
> The URL is meant to be delivered to the AAC runtime, or reverse proxy?

If you're creating a "Server Connection" for (privileged) access to SCIM for User Self Care mechanisms, then this should connect directly to the Runtime.
Effectively the Runtime is connecting to itself so the use of http://localhost/scim is correct.  It is not going via the Reverse Proxy.

If you're creating an access point to the SCIM function for a 3rd party application or for unprivileged access for end users then this should be via the Reverse Proxy.

> If it is the AAC runtime, then localhost or policy server host should used as URL?

Unless you have changed the interface that the runtime listens on, use of localhost is correct.  This is a loopback connection.

> If it is the AAC runtime, as the /scim junction backend server for the reverse proxy is localhost, should this URL be the same? Then what is /scim doing there?

The context-root for the SCIM function in the runtime is /scim so all URLs start with this.  When defining the /scim junction in the Reverse Proxy it is a transparent-path junction so the /scim part of the path is passed on to the runtime.

> When creating a Server Connection for SCIM Web Service, we are supposed to add easuser and its password. Why this user and not Scim Administrator's password? To have permission to make changes in scim we must use a user that belongs to the scim admin Group!

The easuser is (by default) a member of the scimAdmin group defined in the AAC user registry.  If you want to create a new user (or group if you have changed the admin group name in SCIM config) then that's fine.  Using easuser is just the easiest option because it already exists in a new system.

> When Configuring Google reCAPTCHA site key, we must use a Domain. If we have ISVA configured in the intranet, and ISAM has a local domain (e.g. internal.example.com) not visible from internet, what should we use on the Domain parameter?

It is whatever domain the browser is accessing to reach the page showing the reCAPTCHA; it doesn't have to be visible from internet - it's used by Google code that runs in your browser (and probably for CSS protection too).

> Regarding the stepup resource, if we provide /scim apis from ISVA, where we have PUT /Users/{id} as an endpoint shouldn't we we apply the stepup policy to unauthenticated users to the PUT /scim/Users, because if they are authenticated, they should only be able to change their own data, since we already identified the user.
If we were to put a policy on the resource, because it is a Rest API, how can we restrict the stepup only to PUT or POST methods?

If you publish the /scim APIs via the Reverse Proxy, the junction must be configured to send the iv-user and iv-group headers and the SCIM configuration must have authorization enabled.  The SCIM function will know (from iv-group header) that the end user connecting is not an administrator and so will only allow them to view and update their own information.  You should not configure the system in such a way that all users can view/change other users.

If you want to limit access to different HTTP methods this is possible via ACL.  It's even possible to remap which permission bits apply to which methods if you want more fine-grained control.  This isn't step-up though.  You can't specify step-up per method using POPs.  I think you would have to use AAC context-based access for this.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM

Original Message:
Sent: Tue April 20, 2021 12:47 PM
From: Joao Goncalves
Subject: Analysing User Self Care in ISAM Cookbook

Although there are some duplication from USC cookbook and MMFA cookbook both written by Jon Harry, there are some specific thing related to USC that I would like to have further explanation:

• When specifying the URL, which URL should be used? In the cookbook it is used http://localhost/scim.
  • The URL is meant to be delivered to the AAC runtime, or reverse proxy?
    • If it is the reverse proxy, then there must be defined a scim junction, and open http port. Shouldn't this reverse proxy or the junction be restricted to ISAM internal use only, and consequently not available to other users through the reverse proxy? In fact, the /scim junction has the localhost as the backend server.
      • I already user the reverse proxy (not localhost) with the /scim function and seems to work, but it is inefficient, so there must be a better way of doing this.
    • If it is the AAC runtime, then localhost or policy server host should used as URL?
    • If it is the AAC runtime, as the /scim junction backend server for the reverse proxy is localhost, should this URL be the same? Then what is /scim doing there?

• When creating a Server Connection for SCIM Web Service, we are supposed to add easuser and its password. Why this user and not Scim Administrator's password? To have permission to make changes in scim we must use a user that belongs to the scim admin Group!
• When Configuring Google reCAPTCHA site key, we must use a Domain. If we have ISVA configured in the intranet, and ISAM has a local domain (e.g. internal.example.com) not visible from internet, what should we use on the Domain parameter?
• Regarding the stepup resource, if we provide /scim apis from ISVA, where we have PUT /Users/{id} as an endpoint shouldn't we we apply the stepup policy to unauthenticated users to the PUT /scim/Users, because if they are authenticated, they should only be able to change their own data, since we already identified the user.
  • If we were to put a policy on the resource, because it is a Rest API, how can we restrict the stepup only to PUT or POST methods?

------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994
------------------------------

Joao,

I expect the failure is happening because you don't have a group called scimAdmins defined in the AAC user registry and/or the easuser is not a member of this group.  Use the LMI to create a group called scimAdmins and then add the easuser to it.  That should fix your issue.

I do seem to remember that in some older versions it wasn't possible to add new groups to the AAC user registry but I just tested in 10.0.1.0 and it's possible there.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------

Original Message:
Sent: Wed April 21, 2021 07:14 AM
From: Joao Goncalves
Subject: Analysing User Self Care in ISAM Cookbook

Ok. Let me try to explain what I am experiencing.
In the SCIM configuration, the administration Group  is scimAdmins
scimAdmins is a group defined in a federated ldap server, where there is a basic user named scimadmin that belong to this group.
This user can access successfully scim apis through the reverse proxy where the /scim junction is defined.

Now, I need to implement USC password Reset.
I will need to define a Server connection of type Web Service (I called it localscim).
In this Service connection, I am using the URL: https://localhost/scim and username easuser

When an unauthenticated user tries to reset his password, this connection is used. From what I see in the logs, it tries to use easuser to access /scim endpoints and the system is complaining because easuser does not belong to the group scimAdmins.

How do I specify the user scimadmin to be able do the /scim/Users?filter=email?

If I understand you correctly, I must also have a group in AAC registry with the same name as it was defined in the federated registry (e.g. scimAdmins), and I must have a user (easuser or scimadmin) in the AAC registry that must be a member of scimAdmins!?@!?

------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994

Original Message:
Sent: Wed April 21, 2021 06:54 AM
From: Jon Harry
Subject: Analysing User Self Care in ISAM Cookbook

Hi Joao,

There is some confusion here because you only configure a single "Admin Group" in SCIM configuration but it can be applied in two different ways.

The SCIM app only does its internal authentication against the AAC runtime registry.  This is for the username passed in Basic Authentication header.

For internal (privileged) connection to the SCIM app, this BA header is populated in the SCIM Server Connection.  The user needs to be defined in the AAC runtime registry and needs to be in group with name that matches the "Admin Group" in SCIM configuration.

For external connection to the SCIM app (via Reverse Proxy), the BA header is populated in the junction configuration.  The user needs to be defined in the AAC runtime registry but group membership is not important.   In this case the BA header is just establishing trust between Reverse Proxy and SCIM app.
With this trust established, the SCIM app reads the *real* user and group memberships from iv-user and iv-group HTTP headers.

If a group in iv-groups header matches the "Admin Group" defined in SCIM config then admin permissions are granted. All accounts (and groups) can be viewed and modified.

If the "Admin Group" is not found then the user is non-admin and they can only view and modify their own account.

I hope that helps to explain.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM

Original Message:
Sent: Wed April 21, 2021 06:22 AM
From: Joao Goncalves
Subject: Analysing User Self Care in ISAM Cookbook

Just one additional question that your answer was not clear.
The scim Administration Group, is defined in a federated repository. Its users are basic users.

easuser belongs to the AAC runtime registry. How can I configure the SCIM Web Service URL, username and password, for a basic user to access localhost/scim?

------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994

Original Message:
Sent: Wed April 21, 2021 06:06 AM
From: Jon Harry
Subject: Analysing User Self Care in ISAM Cookbook

Hi Joao,

> When specifying the URL, which URL should be used? In the cookbook it is used http://localhost/scim.
> The URL is meant to be delivered to the AAC runtime, or reverse proxy?

If you're creating a "Server Connection" for (privileged) access to SCIM for User Self Care mechanisms, then this should connect directly to the Runtime.
Effectively the Runtime is connecting to itself so the use of http://localhost/scim is correct.  It is not going via the Reverse Proxy.

If you're creating an access point to the SCIM function for a 3rd party application or for unprivileged access for end users then this should be via the Reverse Proxy.

> If it is the AAC runtime, then localhost or policy server host should used as URL?

Unless you have changed the interface that the runtime listens on, use of localhost is correct.  This is a loopback connection.

> If it is the AAC runtime, as the /scim junction backend server for the reverse proxy is localhost, should this URL be the same? Then what is /scim doing there?

The context-root for the SCIM function in the runtime is /scim so all URLs start with this.  When defining the /scim junction in the Reverse Proxy it is a transparent-path junction so the /scim part of the path is passed on to the runtime.

> When creating a Server Connection for SCIM Web Service, we are supposed to add easuser and its password. Why this user and not Scim Administrator's password? To have permission to make changes in scim we must use a user that belongs to the scim admin Group!

The easuser is (by default) a member of the scimAdmin group defined in the AAC user registry.  If you want to create a new user (or group if you have changed the admin group name in SCIM config) then that's fine.  Using easuser is just the easiest option because it already exists in a new system.

> When Configuring Google reCAPTCHA site key, we must use a Domain. If we have ISVA configured in the intranet, and ISAM has a local domain (e.g. internal.example.com) not visible from internet, what should we use on the Domain parameter?

It is whatever domain the browser is accessing to reach the page showing the reCAPTCHA; it doesn't have to be visible from internet - it's used by Google code that runs in your browser (and probably for CSS protection too).

> Regarding the stepup resource, if we provide /scim apis from ISVA, where we have PUT /Users/{id} as an endpoint shouldn't we we apply the stepup policy to unauthenticated users to the PUT /scim/Users, because if they are authenticated, they should only be able to change their own data, since we already identified the user.
If we were to put a policy on the resource, because it is a Rest API, how can we restrict the stepup only to PUT or POST methods?

If you publish the /scim APIs via the Reverse Proxy, the junction must be configured to send the iv-user and iv-group headers and the SCIM configuration must have authorization enabled.  The SCIM function will know (from iv-group header) that the end user connecting is not an administrator and so will only allow them to view and update their own information.  You should not configure the system in such a way that all users can view/change other users.

If you want to limit access to different HTTP methods this is possible via ACL.  It's even possible to remap which permission bits apply to which methods if you want more fine-grained control.  This isn't step-up though.  You can't specify step-up per method using POPs.  I think you would have to use AAC context-based access for this.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM

Original Message:
Sent: Tue April 20, 2021 12:47 PM
From: Joao Goncalves
Subject: Analysing User Self Care in ISAM Cookbook

Although there are some duplication from USC cookbook and MMFA cookbook both written by Jon Harry, there are some specific thing related to USC that I would like to have further explanation:

• When specifying the URL, which URL should be used? In the cookbook it is used http://localhost/scim.
  • The URL is meant to be delivered to the AAC runtime, or reverse proxy?
    • If it is the reverse proxy, then there must be defined a scim junction, and open http port. Shouldn't this reverse proxy or the junction be restricted to ISAM internal use only, and consequently not available to other users through the reverse proxy? In fact, the /scim junction has the localhost as the backend server.
      • I already user the reverse proxy (not localhost) with the /scim function and seems to work, but it is inefficient, so there must be a better way of doing this.
    • If it is the AAC runtime, then localhost or policy server host should used as URL?
    • If it is the AAC runtime, as the /scim junction backend server for the reverse proxy is localhost, should this URL be the same? Then what is /scim doing there?

• When creating a Server Connection for SCIM Web Service, we are supposed to add easuser and its password. Why this user and not Scim Administrator's password? To have permission to make changes in scim we must use a user that belongs to the scim admin Group!
• When Configuring Google reCAPTCHA site key, we must use a Domain. If we have ISVA configured in the intranet, and ISAM has a local domain (e.g. internal.example.com) not visible from internet, what should we use on the Domain parameter?
• Regarding the stepup resource, if we provide /scim apis from ISVA, where we have PUT /Users/{id} as an endpoint shouldn't we we apply the stepup policy to unauthenticated users to the PUT /scim/Users, because if they are authenticated, they should only be able to change their own data, since we already identified the user.
  • If we were to put a policy on the resource, because it is a Rest API, how can we restrict the stepup only to PUT or POST methods?

------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994
------------------------------

I'll do that, but in my opinion it is an awkward solution, to require that the same group name to be defined in 2 different registries for this to work.
But thanks for the information.

------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994
------------------------------

Original Message:
Sent: Wed April 21, 2021 07:23 AM
From: Jon Harry
Subject: Analysing User Self Care in ISAM Cookbook

Joao,

I expect the failure is happening because you don't have a group called scimAdmins defined in the AAC user registry and/or the easuser is not a member of this group.  Use the LMI to create a group called scimAdmins and then add the easuser to it.  That should fix your issue.

I do seem to remember that in some older versions it wasn't possible to add new groups to the AAC user registry but I just tested in 10.0.1.0 and it's possible there.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM

Original Message:
Sent: Wed April 21, 2021 07:14 AM
From: Joao Goncalves
Subject: Analysing User Self Care in ISAM Cookbook

Ok. Let me try to explain what I am experiencing.
In the SCIM configuration, the administration Group  is scimAdmins
scimAdmins is a group defined in a federated ldap server, where there is a basic user named scimadmin that belong to this group.
This user can access successfully scim apis through the reverse proxy where the /scim junction is defined.

Now, I need to implement USC password Reset.
I will need to define a Server connection of type Web Service (I called it localscim).
In this Service connection, I am using the URL: https://localhost/scim and username easuser

When an unauthenticated user tries to reset his password, this connection is used. From what I see in the logs, it tries to use easuser to access /scim endpoints and the system is complaining because easuser does not belong to the group scimAdmins.

How do I specify the user scimadmin to be able do the /scim/Users?filter=email?

If I understand you correctly, I must also have a group in AAC registry with the same name as it was defined in the federated registry (e.g. scimAdmins), and I must have a user (easuser or scimadmin) in the AAC registry that must be a member of scimAdmins!?@!?

------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994

Original Message:
Sent: Wed April 21, 2021 06:54 AM
From: Jon Harry
Subject: Analysing User Self Care in ISAM Cookbook

Hi Joao,

There is some confusion here because you only configure a single "Admin Group" in SCIM configuration but it can be applied in two different ways.

The SCIM app only does its internal authentication against the AAC runtime registry.  This is for the username passed in Basic Authentication header.

For internal (privileged) connection to the SCIM app, this BA header is populated in the SCIM Server Connection.  The user needs to be defined in the AAC runtime registry and needs to be in group with name that matches the "Admin Group" in SCIM configuration.

For external connection to the SCIM app (via Reverse Proxy), the BA header is populated in the junction configuration.  The user needs to be defined in the AAC runtime registry but group membership is not important.   In this case the BA header is just establishing trust between Reverse Proxy and SCIM app.
With this trust established, the SCIM app reads the *real* user and group memberships from iv-user and iv-group HTTP headers.

If a group in iv-groups header matches the "Admin Group" defined in SCIM config then admin permissions are granted. All accounts (and groups) can be viewed and modified.

If the "Admin Group" is not found then the user is non-admin and they can only view and modify their own account.

I hope that helps to explain.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM

Original Message:
Sent: Wed April 21, 2021 06:22 AM
From: Joao Goncalves
Subject: Analysing User Self Care in ISAM Cookbook

Just one additional question that your answer was not clear.
The scim Administration Group, is defined in a federated repository. Its users are basic users.

easuser belongs to the AAC runtime registry. How can I configure the SCIM Web Service URL, username and password, for a basic user to access localhost/scim?

------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994

Original Message:
Sent: Wed April 21, 2021 06:06 AM
From: Jon Harry
Subject: Analysing User Self Care in ISAM Cookbook

Hi Joao,

> When specifying the URL, which URL should be used? In the cookbook it is used http://localhost/scim.
> The URL is meant to be delivered to the AAC runtime, or reverse proxy?

If you're creating a "Server Connection" for (privileged) access to SCIM for User Self Care mechanisms, then this should connect directly to the Runtime.
Effectively the Runtime is connecting to itself so the use of http://localhost/scim is correct.  It is not going via the Reverse Proxy.

If you're creating an access point to the SCIM function for a 3rd party application or for unprivileged access for end users then this should be via the Reverse Proxy.

> If it is the AAC runtime, then localhost or policy server host should used as URL?

Unless you have changed the interface that the runtime listens on, use of localhost is correct.  This is a loopback connection.

> If it is the AAC runtime, as the /scim junction backend server for the reverse proxy is localhost, should this URL be the same? Then what is /scim doing there?

The context-root for the SCIM function in the runtime is /scim so all URLs start with this.  When defining the /scim junction in the Reverse Proxy it is a transparent-path junction so the /scim part of the path is passed on to the runtime.

> When creating a Server Connection for SCIM Web Service, we are supposed to add easuser and its password. Why this user and not Scim Administrator's password? To have permission to make changes in scim we must use a user that belongs to the scim admin Group!

The easuser is (by default) a member of the scimAdmin group defined in the AAC user registry.  If you want to create a new user (or group if you have changed the admin group name in SCIM config) then that's fine.  Using easuser is just the easiest option because it already exists in a new system.

> When Configuring Google reCAPTCHA site key, we must use a Domain. If we have ISVA configured in the intranet, and ISAM has a local domain (e.g. internal.example.com) not visible from internet, what should we use on the Domain parameter?

It is whatever domain the browser is accessing to reach the page showing the reCAPTCHA; it doesn't have to be visible from internet - it's used by Google code that runs in your browser (and probably for CSS protection too).

> Regarding the stepup resource, if we provide /scim apis from ISVA, where we have PUT /Users/{id} as an endpoint shouldn't we we apply the stepup policy to unauthenticated users to the PUT /scim/Users, because if they are authenticated, they should only be able to change their own data, since we already identified the user.
If we were to put a policy on the resource, because it is a Rest API, how can we restrict the stepup only to PUT or POST methods?

If you publish the /scim APIs via the Reverse Proxy, the junction must be configured to send the iv-user and iv-group headers and the SCIM configuration must have authorization enabled.  The SCIM function will know (from iv-group header) that the end user connecting is not an administrator and so will only allow them to view and update their own information.  You should not configure the system in such a way that all users can view/change other users.

If you want to limit access to different HTTP methods this is possible via ACL.  It's even possible to remap which permission bits apply to which methods if you want more fine-grained control.  This isn't step-up though.  You can't specify step-up per method using POPs.  I think you would have to use AAC context-based access for this.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM

Original Message:
Sent: Tue April 20, 2021 12:47 PM
From: Joao Goncalves
Subject: Analysing User Self Care in ISAM Cookbook

Although there are some duplication from USC cookbook and MMFA cookbook both written by Jon Harry, there are some specific thing related to USC that I would like to have further explanation:

• When specifying the URL, which URL should be used? In the cookbook it is used http://localhost/scim.
  • The URL is meant to be delivered to the AAC runtime, or reverse proxy?
    • If it is the reverse proxy, then there must be defined a scim junction, and open http port. Shouldn't this reverse proxy or the junction be restricted to ISAM internal use only, and consequently not available to other users through the reverse proxy? In fact, the /scim junction has the localhost as the backend server.
      • I already user the reverse proxy (not localhost) with the /scim function and seems to work, but it is inefficient, so there must be a better way of doing this.
    • If it is the AAC runtime, then localhost or policy server host should used as URL?
    • If it is the AAC runtime, as the /scim junction backend server for the reverse proxy is localhost, should this URL be the same? Then what is /scim doing there?

• When creating a Server Connection for SCIM Web Service, we are supposed to add easuser and its password. Why this user and not Scim Administrator's password? To have permission to make changes in scim we must use a user that belongs to the scim admin Group!
• When Configuring Google reCAPTCHA site key, we must use a Domain. If we have ISVA configured in the intranet, and ISAM has a local domain (e.g. internal.example.com) not visible from internet, what should we use on the Domain parameter?
• Regarding the stepup resource, if we provide /scim apis from ISVA, where we have PUT /Users/{id} as an endpoint shouldn't we we apply the stepup policy to unauthenticated users to the PUT /scim/Users, because if they are authenticated, they should only be able to change their own data, since we already identified the user.
  • If we were to put a policy on the resource, because it is a Rest API, how can we restrict the stepup only to PUT or POST methods?

------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994
------------------------------