License

Please notice that the standard version of Safewhere*Identify only provides 1 month trial license. If you have purchased a license from Safewhere*Identify, you will receive a license file. This license file should be stored in the bin folder of each web application. In other words, given that an instance of Safewhere*Identify (a tenant) is deployed to C:\Program files\Safewhere\Identify_tenant1\Admin and C:\Program files\Safewhere\Identify_tenant1\Runtime, the license file must be put into the Admin\bin and Runtime\bin folders. The License can also be put in just one location under C:\Windows\System32.

Security

We have made considerable efforts in regards to closing all possible security holes. This section answers some of the security concerns that there may be in regards to Safewhere*Identify.

IIS Detailed Error Message Information Leak

It is important to ensure that IIS does not reveal information through its detailed error messages from Safewhere*Identify by setting IIS up correctly, since we cannot control this from the Safewhere*Identify code and installer.

Detailed error messages can include diagnostics, path and OS information, software versions, and other sensitive information of use to attackers. IIS 7.0 by default only shows detailed error messages to clients coming from the local server IP address, but developers often enabled remote detailed error messages when making and testing code changes, so please beware.

In order to disable the detailed remote error messages you should follow these steps:

1. Open the IIS 7.0 Manager
2. Select the affected Website and click on “Error Pages” in the features view
3. Right click and select “Edit feature settings”
4. Now you can select either “Detailed errors for local requests and custom error pages for remote users” or “Custom error pages”

Security Issues that we have managed since Version 3.1

• Admin site as RP will accept the no-assertion response and show error message.
• Various checks against bottleneck problems.
• Defense against extreme data size attacks (typically large XML files) for both Admin (e.g. upload metadata) and Runtime (token sizes send via SAML and WS-Federation). In addition, tests made for OCES and NemID.
• Defense against unauthorized access to data via modifying object requests from client side beyond what UI allows.
• Defense against revealing sensitive information using login pages.
• Removal of all system error messages ensuring limited revelation of system structure.
• Attack on hidden fields and read-only fields of UIs.
• For ASP.Net authentication cookie, each application is now given a unique name.
• Configurator ensures that custom errors are not disabled and debugging is.
• Encryption of FedAuth cookie.
• Defense against replay attacks (expiry check, duplicated security token) implemented for FedAuth, ASP.Net session ID, OCES, NemID, SAML, WS-Federation.
• Defense against injection attacks and injection challenge code (Subject injection, DTD Injection, Change attribute) for NemID and OCES, SAML and WS-Federation.
• Defense against signature attacks (corrupt signature, signature removal, attributes signature attack/signature remote attack, wtrealm injection attack, ADFS 2.0 to sign both message and assertion, etc) for SAML and WS-Federation.
• Various testing and improvements in regards to defense against tampering with input, XSS attack, magic URLs, “switch” parameters in URLs or form data, cookie, and usage of headers.
• Extensive testing of the metadata upload feature including defending it against large files, files with very large external DTD, and malicious XML files.
• Support for preventing CDC redirect attacks.
• Support for handling DoS/DDoS attacks. Although the means to carry out, motives for, and targets of a DoS attack may vary, it generally consists of the concerted efforts of a person, or multiple people to prevent an Internet site or service from functioning efficiently or at all, temporarily or indefinitely.