Security

SSL Certification Needs

Student Success Dashboard, like many websites today, uses a SSL Certificate for security purposes such as login information. The certificates have been getting stored in Applications => StudentSuccessDashboard => Certificates:

The current certificate in the project is nothing more than a test certificate for development purposes that causes a security exception whenever users go to the website. It will need to be replaced by your own SSL certificate. A SSL certificate lets users know you are who you say you are. A valid SSL can be acquired from multiple sources such as VeriSign or Symantec. One other item of note here is that the SSD Post-build event attaches the certificate to the development versions of the website:

This is done with the command: “CERTUTIL -importPFX -f -v -p 123456 my $(ProjectDir)Certificates\SiteCertificate.pfx”. If this command doesn’t execute, then the website will be unable to run locally.

Once you’ve installed your certificate, you’ll need to grab the thumbprint for it. This can be done by grabbing it from the Service Definition in the Azure project. If you right click the Azure project and go to properties, you’ll see the Certificates tab and can find it from there:

This thumbprint then needs to be added to the web.config file in 2 places:

Once this is done, the certificate must be uploaded to Azure through the Windows Azure Portal. Login through the portal and navigate to the Cloud Services tab. Then select the service you want to upload the certificate to. Lastly, select the Certificates tab followed by clicking the Upload button at the bottom of the screen to upload it:

You will then need to navigate to the Active Directory section and go to the Azure Control Namespaces tab. This is needed for so the certificate can sign ACS tokens when users use the application. From there, select which namespace you want to upload the certificate to and click the Manage button. This opens an Azure Control Service page for that namespace. Go to the Certificates and Keys section and from there you can add your certificate to the namespace:

Machine Key

For the purposes of this application, you will need to create a machine key and place it in the web.config file under the tag. Typically a machine key looks something like this:

<machineKey validation="HMACSHA256" validationKey="…" decryption="AES" decryptionKey="…"/\>

The validation and decryption keys can be auto-generated through your own tool or something online. It merely needs to be a complex set of random characters that will be hard to hack through. This application uses the machineKey as a signature on the session token to help make it tamper-proof.

Strong Name Keys

In this application we have used strong name keys for our assemblies and it’s suggested that you would want to as well. Strong Name Keys provide a way to uniquely identify each assembly and avoid “DLL Hell” as well as potentially keeping hackers from overriding your assemblies. To accomplish this, first right-click on the project you’re going to apply the SNK to and select properties. In the properties window, select the “Signing” section and click the checkbox next to “Sign the assembly”. You can create a new SNK or use an old one from the “Choose a strong name key file” dropdown:

Once you’ve done that, any InternalsVisibleTo you’ve made referencing that project will need the PublicKeyToken from that SNK. You can retrieve this from the command line using a command similar to “sn.exe -T assembly.dll”. Otherwise, those projects will no longer be able to get the internals from that assembly. Lastly, the PublicKeyToken you’ve retrieved will also need to be added to the WsFederationAuthenticationModule tag in the web.config file. It should look like:

<add name="WsFederationAuthenticationModule" type="Security.AuthenticationModule, SSD.Security, Version=1.0.0.0, Culture=neutral, PublicKeyToken="…" preCondition="managedHandler" /\>

Return to the wiki Home.