I've been doing some testing with configuring Oauth2 by creating a definition and client under the OpenID Connect and API Protection in ISAM. Everything is working as expected. 

From the Advanced Access Control Configuration topics documentation for 9.0.6 I see the following:
When you create policies, policy sets, or API protection definitions you cannot use
them until you publish them to resources. Once policies, policy sets, or API
protection definitions are published, they are enforced during the evaluation of
access requests.

However, I've noticed that it works as expected regardless if I have a "Resource" attached with a published API Protection definition or not. In fact, when I do attach the definition, the only change I can see is it adds the following POP to the junction:

pdadmin sec_master> pop show oauth-pop
Protected object policy: oauth-pop
Description:
Warning: No
Audit level: none
Quality of protection: none
Time of day access: sun, mon, tue, wed, thu, fri, sat, :anytime:local
IP Endpoint Authentication Method Policy
Auth Level: 0 Network: Any Other Network

Am I missing some step somewhere? Looking at this POP it doesn't seem to do anything. 

Thanks,
Scott




------------------------------
Scott Reichardt
ISAM 9.0.6
------------------------------

Hi Scott,

There are multiple ways that you can implement OAuth 2.0 Enforcement in Access Manager.

1) OAuth-Auth.  This is the default method.  When WebSEAL detects an incoming Bearer header, it forwards the Token to the AAC Runtime.  The AAC Runtime validates the token and returns user information which WebSEAL uses to build a credential.  When using this method, Access Tokens are accepted whenever they are presented... no need to define resources (as you discovered).

2) OAuth-EAS.  This is an old method.  Checking for a Bearer Token is only done for resources that have an API Definition attached.  The Access Token is sent to AAC Runtime which determines if is is valid or not.  If valid, request is permitted.   Otherwise request is denied.  No user credential is created so you are quite limited on other authorization you can do and information you can pass to backend.  This was the original way OAuth was implemented and required the use of Resources attachment.  (the POP you see is what triggers the OAuth EAS module... same way that AAC policies are triggered actually).  Only advantage of this method (that I can think of) is that you can use different OAuth Definitions for different parts of the objectspace.

3) In 9.0.7.0 we support ability for WebSEAL to call a standard (likely 3rd Party) Introspection endpoint to validate received Access Tokens.  The information returned from the Introspection endpoint is used to build a credential (like OAuth-Auth).  No need for resource attachment here either.

I hope this helps to explain what you're seeing.

Cheers... Jon.

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

P.S. The "secret" in the POP is in the extended attributes.  There's a parameter which causes a specified EAS to be triggered.

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

Original Message:
Sent: Wed November 13, 2019 11:33 AM
From: Jon Harry
Subject: "Resources" under OpenID Connect and API Protection

Hi Scott,

There are multiple ways that you can implement OAuth 2.0 Enforcement in Access Manager.

1) OAuth-Auth.  This is the default method.  When WebSEAL detects an incoming Bearer header, it forwards the Token to the AAC Runtime.  The AAC Runtime validates the token and returns user information which WebSEAL uses to build a credential.  When using this method, Access Tokens are accepted whenever they are presented... no need to define resources (as you discovered).

2) OAuth-EAS.  This is an old method.  Checking for a Bearer Token is only done for resources that have an API Definition attached.  The Access Token is sent to AAC Runtime which determines if is is valid or not.  If valid, request is permitted.   Otherwise request is denied.  No user credential is created so you are quite limited on other authorization you can do and information you can pass to backend.  This was the original way OAuth was implemented and required the use of Resources attachment.  (the POP you see is what triggers the OAuth EAS module... same way that AAC policies are triggered actually).  Only advantage of this method (that I can think of) is that you can use different OAuth Definitions for different parts of the objectspace.

3) In 9.0.7.0 we support ability for WebSEAL to call a standard (likely 3rd Party) Introspection endpoint to validate received Access Tokens.  The information returned from the Introspection endpoint is used to build a credential (like OAuth-Auth).  No need for resource attachment here either.

I hope this helps to explain what you're seeing.

Cheers... Jon.

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

This explains it perfectly. Thanks Jon!

------------------------------
Scott Reichardt
------------------------------

Original Message:
Sent: Wed November 13, 2019 11:33 AM
From: Jon Harry
Subject: "Resources" under OpenID Connect and API Protection

Hi Scott,

There are multiple ways that you can implement OAuth 2.0 Enforcement in Access Manager.

1) OAuth-Auth.  This is the default method.  When WebSEAL detects an incoming Bearer header, it forwards the Token to the AAC Runtime.  The AAC Runtime validates the token and returns user information which WebSEAL uses to build a credential.  When using this method, Access Tokens are accepted whenever they are presented... no need to define resources (as you discovered).

2) OAuth-EAS.  This is an old method.  Checking for a Bearer Token is only done for resources that have an API Definition attached.  The Access Token is sent to AAC Runtime which determines if is is valid or not.  If valid, request is permitted.   Otherwise request is denied.  No user credential is created so you are quite limited on other authorization you can do and information you can pass to backend.  This was the original way OAuth was implemented and required the use of Resources attachment.  (the POP you see is what triggers the OAuth EAS module... same way that AAC policies are triggered actually).  Only advantage of this method (that I can think of) is that you can use different OAuth Definitions for different parts of the objectspace.

3) In 9.0.7.0 we support ability for WebSEAL to call a standard (likely 3rd Party) Introspection endpoint to validate received Access Tokens.  The information returned from the Introspection endpoint is used to build a credential (like OAuth-Auth).  No need for resource attachment here either.

I hope this helps to explain what you're seeing.

Cheers... Jon.

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