The document outlines the software requirements specification for a single sign-on solution using Active Directory Federation Services, Windows Identity Foundation, and SAML. It describes the scope of the project including implementing an STS service with AD FS and configuring identity and service providers. Key requirements include transparent SSO between applications, configurable source and destination providers, and an administrative console to manage solution entities and service accounts. Security requirements ensure resilience, availability, auditing, and protection of security information exchanged.

1. Single Sign On/Federation via AD FS/WIF/SAML
Software Requirements Specification
Group Id: F1202FBFA8 (MC110403218)
Supervisor Name: Sarfraz Ahmad Awan (sawan@vu.edu.pk)

2. Revision History
Date Version Description Author
11/2/1012 1.0 Initial Draft for all the basic elements MC110403218
of SRS document
11/5/2012 1.1 Added scope for project and MC110403218
Refined use cases.
11/5/2012 1.2 Labeled as version 1.2 send to MC110403218
Sarfraz Ahmad Awan as
assignment no 1

3. Contents
Overview....................................................................................................................................3
Scope..........................................................................................................................................4
Software Requirement................................................................................................................5
User Case Diagram.....................................................................................................................6
Use case Explanation..................................................................................................................7
..........................................................................................................................................9
Overview
1.1 Introduction
Single Sign On (SSO) (also known as Enterprise Single Sign On or "ESSO") is the ability for
a user to enter the same id and password to logon to multiple applications within an
enterprise. As passwords are the least secure authentication mechanism, single sign on has
now become known as reduced sign on (RSO) since more than one type of authentication
mechanism is used according to enterprise risk models.

4. 1.2 Competitor solution
For details, please visit:
http://en.wikipedia.org/wiki/List_of_single_sign-on_implementations
1.3 Implementation technologies
Microsoft .Net Framework / C#
WIF http://en.wikipedia.org/wiki/Windows_Identity_Foundation
SAML http://en.wikipedia.org/wiki/SAML_2.0
WS-Trust http://en.wikipedia.org/wiki/WS-Trust
WS-Security http://en.wikipedia.org/wiki/WS-Security
Scope
1.4 Architecture Scope Options
1.4.1 Implementation via Federation Server for SSO
Federation server can be implemented to handle federation mechanism for SSO.
It would be best laid architecture. But can be out of scope for current course. A POC will be
done to make sure that the current scope is properly under stood.
Scope can be dependent on design phase of the project.

5. 1.4.2 Development of STS Service for SSO
AD FS will act as STS Service. Scope for AD FS can be dependent on design phase of the
project.
1.4.3 Identity Providers to cover for SSO
Currently Active directory is primary scope as Identity provider.
1.4.4 Service Providers to cover for SSO
ASP .Net business applications like HR application will act as service provider for current
implementation.
1.4.5 OS scope for SSO
Current project will only cover Windows Server 2012 as testing and development
environment for Server operating system.
Current project will only cover Windows 8 as testing and development environment for client
operation system.
1.4.6 SAML Implementation Scope
Windows Identity Foundation have SAML 2.0 implementation as extension as explained in
http://connect.microsoft.com/site1168/Downloads/DownloadDetails.aspx?
DownloadID=36088
This will be current scope of SAML 2.0 implementation.
Software Requirement
1.5 Functional Software Requirement
1.5.1 Transparent SSO
For end user there should not be any visual indicator that user is moving from one application
to another. Means for end user it should be transparent SSO.
1.5.2 Source and destination
Source and destination Provider should be configurable.
1.5.3 Administrator Console
• There should not be any hard coding for entities evolved in solution like Identity provider or
Service Provider.
• STS Service should not be hard coded; there must an interface to change URL for STS
Service.
• Service accounts for solution must be configurable via UI interface.

6. 1.6 Non-Functional Software Requirement
1.6.1 Performance Requirements
SSO must be performed with no delays. Robust redirection should be provided from source
to destination.
1.6.2 Security Requirements
The security requirements to be met by an implementation of SSO are:
• SSO shall not adversely affect the resilience of the system within which it is deployed.
• SSO shall not adversely impact the availability of any individual system service.
• An SSO implementation shall audit all security relevant events which occur within the context
of the XSSO.
• An SSO implementation shall protect all security relevant information supplied to or generated
by the XSSO implementation such that other services may adequately trust the integrity and origin of
all security information provided to them as part of a secondary sign-on operation.
• The SSO shall provide protection to security relevant information when exchanged between
its own constituent components and between those components and other services.
User Case Diagram

7. Use case Explanation
Explanation for only primary use cases (Those mainly used by actors) is written below.
1.7 Use Case Id 00001
Use Case Title Configure SSO Provider
Abbreviated Title C_SSO_Provider
Use Case Id 00001
Requirement Id 3.1.2 , 3.1.3
Description:
It is administrative task and will be performed by SSO Admin
Pre Conditions: Solution is properly installed. STS Service is already installed.
Task Sequence Exceptions
1. Open MMC for SSO
2. Identify the Source or destination - type of provider to configure.
3. Provide configuration like URL or other related info. Some provider might
not have URL
4. Provide Service account info for configuration like user name and Some provider might
password give anonymous
access.
.
Post Conditions: Provider is tested and returns positive response to SSO admin.
Unresolved issues:
Authority: Shahzad Sarwar
Modification history: Initial Draft
Author: Shahzad Sarwar
Description: Needs review by Course Supervisor : Sarfraz Ahmad Awan
1.8 Use Case Id 00002
Use Case Title Configure Identity Privder
Abbreviated Title C_I_Privder
Use Case Id 00002
Requirement Id 3.1.2 , 3.1.3
Description:
It is administrative task and will be performed by SSO Admin
Pre Conditions:
Solution is properly installed.
STS Service is already installed.
Identify Provider is reachable.
Task Sequence Exceptions

8. 1.6 Non-Functional Software Requirement
1.6.1 Performance Requirements
SSO must be performed with no delays. Robust redirection should be provided from source
to destination.
1.6.2 Security Requirements
The security requirements to be met by an implementation of SSO are:
• SSO shall not adversely affect the resilience of the system within which it is deployed.
• SSO shall not adversely impact the availability of any individual system service.
• An SSO implementation shall audit all security relevant events which occur within the context
of the XSSO.
• An SSO implementation shall protect all security relevant information supplied to or generated
by the XSSO implementation such that other services may adequately trust the integrity and origin of
all security information provided to them as part of a secondary sign-on operation.
• The SSO shall provide protection to security relevant information when exchanged between
its own constituent components and between those components and other services.
User Case Diagram