Srs sso-version-1.2-stable version-0

2,798 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,798
On SlideShare
0
From Embeds
0
Number of Embeds
1,621
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Srs sso-version-1.2-stable version-0

  1. 1. Single Sign On/Federation via AD FS/WIF/SAML Software Requirements SpecificationGroup Id: F1202FBFA8 (MC110403218)Supervisor Name: Sarfraz Ahmad Awan (sawan@vu.edu.pk)
  2. 2. Revision History Date Version Description Author11/2/1012 1.0 Initial Draft for all the basic elements MC110403218 of SRS document11/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. 3. Contents Overview....................................................................................................................................3 Scope..........................................................................................................................................4 Software Requirement................................................................................................................5 User Case Diagram.....................................................................................................................6 Use case Explanation..................................................................................................................7 ..........................................................................................................................................9 Overview1.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. 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 Options1.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. 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 Requirement1.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. 6. 1.6 Non-Functional Software Requirement1.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. 7. Use case ExplanationExplanation for only primary use cases (Those mainly used by actors) is written below.1.7 Use Case Id 00001Use Case Title Configure SSO ProviderAbbreviated Title C_SSO_ProviderUse Case Id 00001Requirement Id 3.1.2 , 3.1.3Description:It is administrative task and will be performed by SSO AdminPre Conditions: Solution is properly installed. STS Service is already installed.Task Sequence Exceptions1. Open MMC for SSO2. Identify the Source or destination - type of provider to configure.3. Provide configuration like URL or other related info. Some provider might not have URL4. Provide Service account info for configuration like user name and Some provider mightpassword give anonymous access..Post Conditions: Provider is tested and returns positive response to SSO admin.Unresolved issues:Authority: Shahzad SarwarModification history: Initial DraftAuthor: Shahzad SarwarDescription: Needs review by Course Supervisor : Sarfraz Ahmad Awan1.8 Use Case Id 00002Use Case Title Configure Identity PrivderAbbreviated Title C_I_PrivderUse Case Id 00002Requirement Id 3.1.2 , 3.1.3Description:It is administrative task and will be performed by SSO AdminPre Conditions:Solution is properly installed.STS Service is already installed.Identify Provider is reachable.Task Sequence Exceptions
  8. 8. 1.6 Non-Functional Software Requirement1.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

×