Support different AS for access_token validation (other then the one processing API call)

[yuriyz]

1. Introduce protect_commands_with_oxd_id: [<oxd id1>, <oxd id2>, ...] in oxd-server.yml.
   RP can register different client with different AS. If protect_commands_with_oxd_id is not set (or missed) then validation should be performed with oxd_id which performs API call (as it is now). If it's set then validation should be performed with oxd_id set from configuration.

2. Add support for AuthorizationOxdId: <oxd_id> HTTP header. It should specify exactly one oxd_id. If it's missed, then we validate against API calls oxd_id (as it is now) but RP can specify different oxd_id in this header, in this case we : a) validate it's among protect_commands_with_oxd_id array, if no, reject call. If yes, then go on validation with oxd_id specified in that header.

3. Remove org.gluu.oxd.common.params.HasAccessTokenParams interface. It was introduced when validation was performed by sockets. Now validation must be performed directly in org.gluu.oxd.server.RestResource#validateAccessToken method.

4. Add step-by-step documentation how to perform validation with different AS.

[duttarnab]

@yuriyz, re: #2 can we keep org.gluu.oxd.common.params.HasAccessTokenParams as marker interface so that we can identify from request param if the command needs access token validation.

[yuriyz]

@duttarnab you can get it from CommandType, 8c4f2d1

[yuriyz]

@duttarnab updated ticket description with AuthorizationOxdId, please check. In this way we can support multiple AS's for API calls as well as multiple AS's for access_token validation.

[duttarnab]

@yuriyz ,
Q1: What I understand is it only related to validation of commands against API calls (in other words for only generating and validating client_token in commands against API calls). Please confirm.

Q2: If the above understanding is true then why we need protect_commands_with_oxd_id as array because we can pass oxd_id directly with AuthorizationOxdId http header. Is it to restrict validation of commands to only certain OPs?

[yuriyz]

@duttarnab
Q1: yes, correct. It's for access_token validation only (that's why it has Authorization* prefix).

Q2: protect_commands_with_oxd_id array is to limit oxd_id's that can be send via AuthorizationOxdId header. Additional security to not be able dynamically register and send oxd_id which is not defined in configuration. However if it's missed from configuration then lets allow to send any oxd_id (AuthorizationOxdId header is not limited). Add tests for it.

[yuriyz]

@duttarnab after this ticket is implemented can you test following scenario: set up AS1 (protection), AS2 (API call), AS3 (protection), AS4 (API call). Register oxd_id for each.

1. Check Authorization Code Flow with AS1 as Authorization and AS2 to which we send API call.
2. Check Authorization Code Flow with AS3 as Authorization and AS4 to which we send API call.

Goal is to get confirmation that oxd supports multiple AS's as API calls as well as protection validation.

[duttarnab]

@yuriyz , Is it a good idea to add oxd_id in the request parameter of /get-client-token and mark client_id, client_secret, op_configuration_endpoint, op_host and op_discovery_path as deprcated. It is more user friendly get client-token just using oxd_id.

Something like:

[yuriyz]

Yes, we can do this but open separate ticket for it since this improvement is not related to current one.

[duttarnab]

Done in 4.2