Check Protected Resource Against CA SSO Assertion

[Muthugomu]

Check Protected Resource Against CA SSO Assertion fails with the same audit message for the the following conditions:

 

1. /hello1 is configured as unprotected resource in CA SSO

2. /hello2 is not configured at all in CA SSO.

 

As you can see from the below screen shot that both of them are returning the same audit message though /hello2 is not configured as either protected or unprotected in CA SSO.

 

 

I have the following requirement:

1. If the resource is protected, meaning if Check Protected Resource Against CA SSO returns true, then force Authenticate against CASSO

2. If the resource is configured as unprotected in CA SSO (Check Protected Resource Against CA SSO is returning false), then do not force Authenticate against CASSO and allow the user to access the resource.

3. If the resource is not at all configured in CA SSO, then return 401 error.

 

Since the Check Protected Resource Against CA SSO fails whether the resource is configured as UNPROTECTED or not configured at all in CA SSO, I cannot determine whether to fail with 401 or allow the user.

 

Is there anything else I can use within API Gateway that can help determine UNPROTECTED and NOT CONFIGURED resource scenarios in CA SSO?

 

Appreciate your help.

[DustinDauncey]

Hello Muthu,

 

I'm not super familiar with the SSO assertion specifically, but I think this would be solved using policy logic such as "At least one must be true" with "All must be true" beneath that policy logic assertion for the different scenarios which you describe.

[Chris Bertagnolli]

Not sure this would work in this scenario? Since the goal is wanting to take two different actions based on what API Gateway is seeing as the same condition: "not protected". But he'd need to explicitly know if it's not protected or not configured.

 

 

IF check resource = protected THEN authenticate user

ELSE IF check resource = not protected THEN allow access

ELSE deny access with 401

 

That basic logic would result in both not protected AND not configured (two different scenarios) to be allowed.

 

Since the "unprotected" returns same result as the "not configured", where would the split happen? Since at the check for protection it would return the same result whether it's not protected or not configured, then access would be allowed but the desire is to return 401 if it's not configured.

 

Without knowing whether it's truly not protected or not configured, there's no way to determine the appropriate action right? Even if you default to "Deny" then check protected resource and it returned "not protected" you still wouldn't know if it's because it's set as not protected and you'd end up allowing access when it should have denied.

[Legacy User]

SSO treats unprotected and undefined the same. 

Unprotected is typically used when parent is protected but we need to unprotected certain areas. E.g. protect from “/“ then configure “/images/“ to be unprotected.

[Chris Bertagnolli]

While functionally to the user it may be the same, there are differences in terms of how you may want to enforce something.

 

CA SSO fails open, which is really annoying actually, in the case of essentially "no policy" versus explicitly told by the system to be "not protected" an admin would want to fail safe and deny access. CA SSO does not do this though, instead it says "oh I have no explicit enforcement policy therefore you can come on in".

 

If the API Gateway allowed us to differentiate between the scenarios then you can fail safe and default DENY all users access unless there's some rule explicitly allowing them.

[Stephen McQuiggan]

Chris

SSO Call isProtected is working as designed

Two ways to configure a resource to unprotected

1. Configure the resources with agent define it in REALM check unprotected (NOTE can't have any rules or it becomes protected)
2. Do not configure agent at all for a specific resource

isProtected call only returns one of two responses yes/no

 

For what you are looking for you need a third response, something like “not configured”

This would need to start with SSO team to be added, then APIM team to implement in assertions. If this is something you think is worthwhile, please open an Idea on the SSO community (CA Single Sign-On)