There are times that practically all of the clients for a server use the same policies. OA4MP allows for specifying QDL scripts to be run for various phases. This simply adds a scripts elements to the standard QDL configuration
One possible use of this would be to add a layer of user management so you could intercept every call and perform user specific tasks (such as linking user accounts).
OA4MP is to be run as a token issuer. This means that auto register is enabled (so anyone/anything may register a public client and it is immediately approved). The security at that point is that the login prevents unwanted access (proxies to a secure service such as CILogon are a great idea.) Each user then has some set of access rights granted based on, e.g., a lookup of their user name in LDAP. Since the identical configuration will be used for each and every client, it would be a very bad idea to boilerplate the code into each and every configuration, just set it in the server configuration.
These scripts reside inside the server <qdl> element. The basic format is
<qdl>
<!-- bunch of configuration for QDL to run -->
<scripts>
<script>
<!-- standard QDL JSON element, exactly like a client script -->
</script>
<scripts>
<!-- As many script elements as you need. -->
</scripts>
</qdl>
Note that server scripts may contain code blocks if you just need a line or two of QDL. and conform to the scripting syntax.
Here the first script is run only in the post_token phase and explicitly sets a couple of claims. It also prints out a debug message saying it is running. The second one loads a test script (and since this runs inside QDL, the script path is used to resolve it). It is only run in the pre_auth phase. The token_type means that the machinery used is the access token, hence access and refresh tokens are availble and changes to them will be saved.
<scripts>
<script>
{"qdl":{"code":[
"x:='my_custom_claim';",
"say('*** IN SERVER SCRIPT');",
"claims.'my_claim':=x;",
"access_token.'my_at_claim':='my_at_claim';",
"refresh_token.'my_rt_claim':='my_rt_claim';"
],
"xmd":{"exec_phase":"post_token"}}}
</script>
<script>
{"qdl":
{
"load":"test.qdl",
"xmd":{"exec_phase":"pre_auth","token_type":"access"},
"args":[4,true,{"server":"localhost","port":443}]
}
}
</script>
</scripts>
Generally all server scripts are run first, then client scripts. Clients, however, may opt to set the attribute skip_server_scripts (also settable using the client management API), thereby not processing any server hooks.