Hi, looking for some help here as I feel I am missing something.
I have an OOP adapter that I want to give access to a jwt sent in Authorisation header.
My instance is configured something like this:
template: authorization
params:
subject:
properties:
app_id: request.auth.claims["azp"] | request.query_params["app_id"] | request.headers["app-id"] | ""
claims: request.auth.raw_claims | ""
However claims is always empty. Do I need to create an additional “Policy” for this to be populated or doing something else wrong?
Thanks
This seems ok… but I’m not sure what you mean by creating an additional “policy”. Basically, as you probably know, an instance, rule, and handler work together to deliver information to an adapter. The instance, as you have above, specifies which fields to populate in the instance. The rule specifies which instances to include in the call to the handler and when. And the handler specifies how Mixer communicates to the adapter.
Since you say claims is always empty… I assume your adapter is already being called by Mixer appropriately? And that you’re receiving the app_id value?
One thing that I find useful is to use ControlZ to turn on the Policy Mixer’s logging to DEBUG for attributes and adapters and then watch the log. Maybe that will help?
Hey thanks,
Yes adapter is receiving traffic from mixer and attributes in all other cases correctly.
Sorry I probably should have been more clear. By Policy I meant configuring end user authn as per https://istio.io/help/ops/security/end-user-auth/
Was not aware of ControlZ, that looks helpful. Will certainly check it out.
Thanks
Aha! Sorry, I should’ve gotten that… yes, you need to create an Authentication Policy to process the JWT. Since everything else is working, that should fix it.
Oh, and just in case it matters to your use case: You can use originIsOptional: true
if you don’t want to prevent the policy from rejecting requests before you get them. In that case, you would receive no claims if a JWT is not provided.
Thanks Scott,
I had a feeling that the attributes might not get processed without the policy in place.
I later added a policy which had http endpoints for the issuer and jwks and could see it being enforced but a valid token was rejected. I’m assuming this was because https is required but perhaps not.
Anyway, many thanks for the pointers.
Philip