Page 56 - MSDN Magazine, March 2018

Database Creation The script file used to create the database for the solution is available for download along with the other artifacts of the solution. Transparent data encryption (TDE) and audit is enabled on the database.
Azure AD and Azure AD B2C Tenant Creation The default Azure AD tenant in the Azure subscription is used as the identity provider for the internal users of the central agency accessing the admin portal. A separate Azure AD tenant is created in this sub- scription where the users representing the insurance companies are registered. These users are added as guest users to the default Azure AD tenant to access the portal applications. If the insurance companies have their own Azure AD tenant, Azure AD B2B can be used to federate that tenant with the default Azure AD tenant in this subscription.
From the Azure Portal, an Azure AD B2C tenant is created in the Azure subscription and policies are defined to permit cus- tomers to self-signup for access to the customer portal. In the identity providers section of the Azure AD B2C configuration, local accounts in this tenant are set to “user name” as opposed to e-mail address, and e-mail verification on user signup is disabled, for simplicity. Refer to the documentation of Azure AD B2C for guidance on creating and configuring policies for the sign-in and sign-up experiences (bit.ly/2n7Vro9).
Running the Application
To allow you to run this solution, I’ve provided sample credentials for signing in to the admin and customer portals in the GitHub repository associated with this article.
To keep the solution simple for this article, I haven’t implemented the step in which insurance companies purchase unique codes. Instead, users of the admin portal would directly execute the next step, where the document serial number, customer information, policy and vehicle details are captured all in one shot.
Figure 3 shows the landing page of the admin portal—Contoso Insurance. You can sign in to the admin portal using the creden- tials of an insurance company user and select Create New to enter
the details for a new document. The document serial number is auto-generated by the application and can be viewed only in the New or Edit Item Form.
Figure 4 shows different versions of the insurance policy data stored as a secret. You can also view additional information, such as content type, tags and attributes. Notice that the Secret is encrypted before it’s stored.
Offline validation can be performed using any QR code reader app on a mobile device, or by using a native Xamarin app.
If you sign in to the customer portal, you can view all the insur- ance policies that were purchased and are ready for activation. The Edit policy page provides an option to activate the policy, which then updates the status of the policy in Azure SQL Database to Active. Once the policy is activated, you can use the Download Policy option, which generates a QR code for the policy data.
Figure 5 shows the user experience on the customer portal for downloading the QR code. Also shown is the JSON data that is read from the QR code using an app on a mobile device. A native app scans the QR code and displays formatted policy details on the screen, for easy offline verification.
Additional security could be implemented by having the customer portal sign the JSON data using a private key in Azure Key Vault and generating a QR code on the signed data. The native mobile app could be shipped with the public key required to verify the signed data before displaying the JSON data on the device for verification.
The customer portal uses the QR code generator for JavaScript, available on GitHub at bit.ly/2sa3TWy, to generate and display the QR code on the portal.
Policy Validation
Policies can be validated either off- line or online. Offline validation can be performed using any QR code reader app on a mobile device, or by using a native Xamarin app. After the QR code is scanned, the results are displayed in a user- friendly way for verification.
In contrast, Figure 6 shows a request for validation sent using the Postman tool (getpostman.com) to the API in the MVC application, which returns the outcome of the validation as a Boolean. In this case, the policy start date is later than the current date so the out- come of the validation is “false.” A
Azure Key Vault
Figure 5 QR Code Generation 50 msdn magazine