License

Please notice that the standard version of Safewhere*Identify only provides a one-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 regard to closing all possible security holes. This section answers some of the security concerns that there may be in regard 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 because 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. By default, IIS 7.0 only shows detailed error messages to clients coming from the local server IP address, but developers often enable remote detailed error messages when making and testing code changes, so please beware.

To disable the detailed remote error messages, follow these steps:

1. Open the IIS 7.0 Manager.
2. Select the affected website and click 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 an 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, and 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 regard 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 might 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.