1. Project Overview

Client is looking for an industry standards based authorization solution which is robust, extremely fast, manageable, and scalable.  The authorization capabilities should be exposed as services which can be consumed across the enterprise, but have a strong affinity or optimization for the RESTful company service layer (ODS or AWM Services), see attachments for detail about this OData/Java oriented capability.  The objective is to expand and leverage industry standards as needed, such as XACML, Spring Security, or even proprietary vendor solution.  Critically, industry standard solutions may need to be enhanced, compliantly extended, or insulated from complex model or relational authorization decisions.

Concepts and Ideas
The diagrams in the "Authorization Draft Architecture and Concepts" and "Example overview secondary" documents offer example views of how we see the Authorization Services generally from a component and capability perspective.  These views draw from industry norms around ABAC, Identity & Access Management, and XACML itself.  The flow description below introduces the concept of an attribute based authorization capability.  Also,"The basic ABAC or XACML authorization flow”.  Significant background can also be pulled from the internet, ABAC, XACML topic and standards.  There are some research notes in the requirements document for now if deep background is desired. 

2. Competition Task Overview

Architects should using the provided documentation to complete the following deliverables:

• System Design Specification
  • The SDS provides multiple system wide views of the application being built. It should explain, at a high level, every architectural decision made in this phase.
• Sequence Diagrams
  • For any major interaction between modules or logical tiers of the application, sequence diagrams must be provided. For system architecture, it is expected that lifelines will correspond to these high level groupings, and need not provide component level interactions. Sequence diagrams should only be necessary where complex interaction will occur between modules. These diagrams should be used to illustrate to the module designers how their modules will be expected to behave.
• Interface Diagrams
  • For any fixed integration point between modules, draft interfaces may be necessary. These interfaces should be considered as recommendations for the module design work to follow. Changes may be necessary as production proceeds, and these diagrams will be superceded by the module level interface diagrams.
• Contest Specification
• Integration Plan

3. Documentation

• Business Requirements
  • The business requirements are drafted in the form of rules for easy understanding of the system requirements. The diagrams depict the business workflow/functionality of the rules
• AuthZ Engine
  • Example overview secondary
• AWM Services (ODS) Overview
• AuthZ Business Function
• XACML Authorization Flow
  • The basic ABAC or XACML authorization flow
• Enterprise AuthZ - Concepts
  • Authorization Draft Architecture and Concepts
• Requirements for AuthZ
  • Introduction, Requirements, Plus some links
• Brokerage_AcctHoldings
  • Example flow for the services layer

Final Submission Guidelines

N/A