Symantec Developer Group

We are working on an application that needs to integrate the with Symantec VIP security solution. I've downloaded the API documentation and the android sample application and I can see that there are at least three pieces of information that are required to provision a credential:

1. The provisioning services URL
2. The provisioning credential prefix
3. The activation code

Our application is designed to allow third parties to provision users for their own VIP installations.  For example customer A who has VIP services enabled wants to be able to have our application provision users for customer A's infrastructure, while a totally unrelated customer B wants to have our application provision users for customer B's infrastructure.

The use case that we're trying to solve is as follows:  A user who needs access to a protected resource using two factor authentication needs to have our application provision them for VIP access at their employer's site with the minimum amount of interaction for that user.  Once the user has been provisioned by our application, all that is needed is that the user enter their password and our application will provide the VIP token for access. Our applicaiton will then gain access to the back end resources that are being protected using VIP services (and which is also developed by us).

Questions:

1. Is the provisioning services URL per-application or per-customer site? So in the example above will customer A have a different provisioning URL to customer B?
2. Is the provisioning prefix also per-customer or per-application? 
3. Is the activiation code provided by the administrator to the user?
4. How is the activation code associated with a user account? Is the link created by the administrator at each customer site?

In terms of provisioning it would be ideal if the user did not need to enter any information into our application during the provisioning process. This could be done by the administrator providing an XML file via email or a URI to the user. Upon opening the file or clicking on the URL our application would be invoked, would consume the required information from the XML file or URI and then provision the user.

Does symantec have such a concept whereby an administrator can send information to the user? For example a tool that could generate the following XML file?

<vip>

   <provisioiningUrl>http://vip.mycompany.com</provisioningUrl>

   <provisioningPrefix>ABCD</provisioningPrefix>

   <activationcode>123456</activationcode>

</vip>

or a URL of the following format?

com.verisign.vip://provision?provisioningUrl=vip.mycompany.com&provisioningPrefix=ABCD&activationCode=123456

An applicaiton could then consume these pieces of information and automatically provision the user.

We could create a tool ourselves but before we do it would be good to know if symantec already has this concept.

Hi leel,

Thanks a lot providing a detailed problem statement and suggesting enhancements that are quite useful. I will suggest you contact your Symantec accounts contact to help you reach out to the VIP Product team to discuss your specific use cases.

Specific questions on the SDK:

• The provisioning services URL - The Symantec hosted URL (depending on pilot vs. production env. this can defer. This is not dependent on the relying party)
• The provisioning credential prefix - Default 'QAMT' is provided for testing in the pilot env only. However, this depends on the customer's choice and needs to be provided before customer decides her production account set up.
  • This can be requested from the OATH community and provided to Symantec to use. In this case, the tokens can be used with other OATH compliant authentication providers as well.  or
  • Symantec can provide the customer the credential prefix which should not be used outside of Symantec VIP authentication env.
• The activation code - A code requested from VIP authentication services from an authenticated relying party which will ensure that the application requesting for VIP credential request is a valid requester with an account with dynamic provisioning enabled. The credential thus created is associated to the relying parties list of dynamic provisioned credentials.

regards,

Sambit