ncsa / oa4mp

Open Authorization for MyProxy
https://oa4mp.org/
Other
7 stars 10 forks source link

HTTPHeaderClaimsSource does not appear to be usable? #180

Closed bbockelm closed 2 months ago

bbockelm commented 4 months ago

It appears that HTTPHeaderClaimsSource is not usable.

It must be run at authorization time, meaning it needs to be a server-level claim source. I.e., you need this in your server-config.xml:

        <scopes
            handler="edu.uiuc.ncsa.myproxy.oa4mp.oauth2.claims.HTTPHeaderClaimsSource"
        />

However, this doesn't seem to enable the claim source. I see this:

OA2ConfigurationLoader | trace:    Actual scope handler = HTTPHeaderClaimsSource

indicating the claim source has loaded. However, when the id token is being generated at the authorization phase:

<localhost> | IDTokenHandler | trace: Starting to process server default claims
<localhost> | IDTokenHandler | trace: Service environment has a claims no source enabled during authorization

It appears that no claim configuration is ever processed, hence the claim source is not enabled -- and no HTTP claims :(

bbockelm commented 4 months ago

In particular, I am working with the device authorization grant.

For device authorization, the pre_auth, auth, and post_auth phases don't exist. I can't add to the claims_source during the phases (which is maybe how this works elsewhere)?

jjg-123 commented 4 months ago

One clarification is needed: Are you using a proxy server for authorization with your issuer? The proxy server runs the header claim source, since only it has the header claims available. Typically the issuer is a client of the proxy server and this client is configured to return the claims.

bbockelm commented 4 months ago

This is not using an OAuth2 proxy. There is a proxy server in front of Tomcat that controls headers in the incoming request (such as setting the username or groups from the authenticated session).

I'd like OA4MP to be able to consume the headers in the device endpoint (the one the user copy/pastes into the browser) and use them as part of the QDL logic.

jjg-123 commented 3 months ago

Correct. The handler was being flagged as disabled on load. However, there are much better ways to do this as per https://github.com/ncsa/oa4mp/issues/188

jjg-123 commented 3 months ago

This requires a code change. Note that this code change also will allow for having scripts run in the pre and post auth phase. However, adding a global handler for a Java class (not configurable) is not the way to do this -- that exists as a hook so you can write a Java implementation. (And should be deprecated, btw).

The better way to have a global handler (in QDL) is to set scripts(s) per phase in the server configuration. This is documented here: https://oa4mp.org/server/configuration/qdl-config.html in the section called Scripts. Do read the final exegesis at some point.