In this issue of APIs by Example, Carsten Flensburg demonstrates the Profile Token APIs.
Profile tokens are a way to change a job so that it runs with the authority of a different user profile. They are similar to the profile handle APIs, except profile tokens can be transferred from one job to another.
This functionality is useful when you’re writing a server program that provides services to a network. When a client program first connects to your server program, you can ask that client for a user name and password. You can use the user name & password to generate a profile token and send that profile token back to the client.
In future requests, the client can re-send you the profile token and you can set the server’s authority to that of the profile token. This ensures that the server runs with the user’s authority and lets you control the user’s access using the normal OS/400 security functions.
When a profile token is generated, you tell the system how long the token is good for — this “time-out” can be from 1 to 3600 seconds. This time-out mechanism provides added security to your system, preventing a would-be attacker from saving and re-using a profile token.
The profile token APIs can also be used to generate a profile token from a previous profile token. You can use this function as a method of “renewing” a profile’s access to the system without asking for the user name and password again.
You can also invalidate a profile token so that it’s no longer valid. This allows profile tokens to be disabled without waiting for the time-out period to elapse.
The difference between the Profile Token APIs and the older Profile Handle APIs is that profile handles can’t be transferred from job to job, but profile tokens can. This added capability makes profile tokens much more flexible than profile handles.
