Hi Timothy,
A fix for the issue which prevented resource servers from being created with the case-insensitive has been included in the v21.09 release which has been published this week.
The forum appears to have messed with the formatting, your YAML definition looks correct but for clarity I'll try to repeat it below:
resource_servers:
- path: "/"
connection_type: "SSL"
servers:
- host: 192.168.1.2
virtual_host: api.domain.local
port: 443
url_style:
case_insensitive: true
I hope you are able to move to the v21.09 release and see better results.
Thanks,
------------------------------
Keiran Robinson
IBM Application Gateway Development
IBM Security Verify Access Development
IBM Security
------------------------------
Original Message:
Sent: Mon September 27, 2021 11:45 AM
From: Timothy Dilbert
Subject: Restricting API Clients access to IAG-protected internal API
Hi Scott,
Yes, we do. I have raised a Support ticket with IBM Support. Let's see what they come back with.
I will try to remember to post an update here once we get to the bottom of all of this.
------------------------------
Timothy Dilbert
Original Message:
Sent: Mon September 27, 2021 12:29 AM
From: Scott Exton
Subject: Restricting API Clients access to IAG-protected internal API
Timothy,
You aren't doing anything wrong. This looks to be an issue with the software. Are you able to raise an IBM support ticket so that the issue can be investigated and fixed?
Thanks.
Scott A. Exton
Senior Software Engineer
Chief Programmer - IBM Security Verify Access
IBM Master Inventor
Original Message:
Sent: 9/26/2021 11:16:00 PM
From: Timothy Dilbert
Subject: RE: Restricting API Clients access to IAG-protected internal API
Unfortunately, I wasn't able to get that to work. See the example below:
resource_servers:
- path: "/"
connection_type: "SSL"
servers:
- host: 192.168.1.2
virtual_host: api.domain.local
port: 443
url_style:
case_insensitive: true
Even with the above, IAG still treats the Paths set under policies > authorization > paths as case sensitive.
What am I doing wrong?
------------------------------
Timothy Dilbert
Original Message:
Sent: Sun September 26, 2021 10:53 PM
From: Scott Exton
Subject: Restricting API Clients access to IAG-protected internal API
Timothy,
Thanks.
Scott A. Exton
Senior Software Engineer
Chief Programmer - IBM Security Verify Access
IBM Master Inventor
Original Message:
Sent: 9/26/2021 10:00:00 PM
From: Timothy Dilbert
Subject: RE: Restricting API Clients access to IAG-protected internal API
Scott,
Using your answer, I was able to partially get there. Within the config.yaml file, we set rules looking for specific scopes. If the access_token has those scopes, then it's permitted to make the calls. Below is an example:
- name: "UserProfiles_Allow" paths: - "/API/userprofiles*" rule: (any scope = "user_profiles") action: "permit"- name: "go-away" paths: - "*" rule: "()" action: "deny"
Per what's above, we make heavy use of Paths. The problem now, however, is that we're finding that IAG treats the paths we set in the config.yaml file as case sensitive. So an access_token with the UserProfiles scope cannot make calls to /api/userprofiles. How can I set a path, but make it case insensitive?
------------------------------
Timothy Dilbert
Original Message:
Sent: Sun September 26, 2021 04:19 PM
From: Scott Exton
Subject: Restricting API Clients access to IAG-protected internal API
Timothy,
IAG uses authorization policies to control access to resources. A policy is selected based on attributes from the request (e.g. path, method, etc), and then an authorization decision is made based on the defined rules for the policy. The rules are applied against attributes from the user's session. Further information can be found at:
https://docs.verify.ibm.com/gateway/docs/concepts-authorization.
In answer to your specific questions:
1. What do you mean by 'level of access'?
2. A scope can be created as a session attribute during authentication (
https://docs.verify.ibm.com/gateway/docs/yaml-identity-oauth). Once the scope if available as a session attribute it is then simply a matter of authoring the rule which utilises the 'scope' attribute, and then creating policies based on the rule to determine when the rule takes affect.
I hope that this helps.
Scott A. Exton
Senior Software Engineer
Chief Programmer - IBM Security Verify Access
IBM Master Inventor
Original Message:
Sent: 9/24/2021 11:03:00 PM
From: Timothy Dilbert
Subject: Restricting API Clients access to IAG-protected internal API
** Overview
We have IAG deployed, and using it to provide OAuth introspection-based authentication to an internal API. The internal API is developed by a third-party provider so we cannot edit the source code to change the authorisation rules within that API. We need a way to restrict API Client's access the third-party API based on URLs.
** Question(s)
We create API Clients in the ISV portal which developers then use to get an access_token and access the IAG-protect third-party API:
- Is there a way through scopes, policies and URLs to control the level of access each API Client has? How would you go about doing that?
- How can we use scopes in the rules we define in IAG config.yaml under policies > authorization?
------------------------------
Timothy Dilbert
------------------------------