Security

• Where located in a Windows domain, SNAP 2.0 implements single-sign on, where the user's standard Windows login is applied when identifying the user. Users external to the domain can login through a standard login/password screen. Having a Windows domain login does not automatically allow access to SNAP however, since SNAP has its own user profiles and logins which are administered separately from the domain.
• SNAP 2.0 interfaces with Active Directory servers. Using the SNAP 2.0 user interface, administrators choose who to add to the SNAP 2.0 user list with a simple point and click interface. User details are read directly from Active Directory and are also periodically updated keeping user details, email addresses and phone numbers synchronised with the Active Directory server.

• SNAP 2.0 uses LINQ to access the database. LINQ automatically prevents SQL-injection attacks as all queries are parameterised, and no literal SQL is built and executed by the application code. The LINQ compilers have been engineered by Microsoft to prevent attackers from forming illegal or unintended SQL.
• Cross-site scripting attacks are also automatically limited by ASP.NET using the "request validation" feature. Request Validation checks the user's input and raises an error if any potentially malicious tags are found.

Architecture

SNAP 2.0 is web based and developed in the latest version of Microsoft .Net using industry standard best practice methodology, providing leading edge technology as standard.

SNAP 2.0 operates within n-tier application architecture, where the user-interface (presentation layer), business rules and data access functionality have been separated from each other into distinct layers: (see draw 1.0)

This gives SNAP 2.0 several advantages within the fields of system design and maintenance:

• Database independence. The layer which handles the business logic does not need to know where the data is stored. New database access modules can be plugged in with a minimum of disruption, allowing SNAP 2.0 to persist its data across a wide range of databases.
• The data access layer has been further enhanced by utilising object-orientated "Interfaces", where the location of every table entity is defined in a configuration file. Configuring SNAP 2.0 to use a different database is as simple as changing an xml file - no recompiling, or even system shutdown is required to switch SNAP 2.0 to a new database. This allows for maximum flexibility if data is required from multiple sources, or if new data sources are needed. The real benefit of implementing this type of design means that SNAP can access any new data source without modifying a single line of existing code. A new module to access a particular data source, e.g. SAP, Oracle, Qube, Sage or even Excel spreadsheets, can be written independently and plugged in to SNAP without affecting existing data access program code, business processing logic or the user interface.
• Fully scaleable - each application layer can be located on physically distinct servers, hence SNAP's absolute scalability in data terms.
• New user interfaces can be created and seamlessly integrated into SNAP without affecting business logic or data access. The mobile layer accesses the same business rules layer as the main Web based front-end, providing the same business rules and logic across multiple user interfaces.
• SNAP 2.0 lives within its own chrome and launches independently from the desktop, ensuring the system is tightly controlled and without third party reliance.

Although company data is sourced from the users' own databases, and posted to the user's finance system, SNAP 2.0 uses industry standard SQL Server 2005 to store its specific data.