Replied 14 May 2018, 2:52 pm EST
Since you already developed a Custom Security Provider, I am sure you are aware that the CreateToken() (which is called on the Login) takes in 3 parameters. The UserName, Password, and Custom. These three are directly passed from the Login endpoint.
Now, the custom security provider is your piece of code so you are able to process these parameters in any way or form that works for your authentication module. The key function of the CreateToken() is to notify to the server that the user is authenticated and provide a securityToken for the server to be able to identify the user for other information, like authorization (based on roles) and userContext values (in case you are using those).
Given this, we have seen many customers use an "identifier" from their application in one of the 3 parameters and pass the others as empty strings. They just use this identifier to call their own application's security module to authenticate the user and get the necessary information required for their ActiveReports Server implementation.
The trick is to ensure your securityToken generated by the security provider is able to validate the user and determine the user roles and other user information necessary. Many times, we have seen customers just re-use the tokens from their own applications to do this as their custom security providers just call their application APIs to use the token for retrieving the user information from their security module.
I hope this helps. In case you need more information, please feel free to comment here or create a support ticket for us to be able to review your code and suggest possibilities specific to your case.