2.5 Security System Services
2.5.3 Security Adaptor Services
The Security Adaptor Services do not constitute a security adaptor in themselves, rather they are the services required by an adaptor created for a specific environment. They are not limited to a single implementation, but an adaptor using these services is required to manage their invocation. Additionally, an adaptor may have its own data store for auth tokens, roles, etc. The services may be used to synchronize the adaptors data with that of the centralized service. It may additionally subscribe to employee and role change messages in the same way as a legacy adaptor to trigger synchronization. This may be necessary to ensure satisfactory performance for a high load system.
For example, a typical adaptor will be able to intercept page requests. If pages have been marked as secure, the adaptor should first check if an auth token is present and that it is valid.
This is done through the checkAuthenticated service.
If a user needs to be authenticated (through a login-page for example) the authenticate service should be called. Once authenticated the checkAuthorization or getAuthorization services can be called to find out what roles the user has been assigned. The adaptor can use these roles to determine if certain resources should be accessed.
The change password service is not, strictly speaking part of the adaptor, since it requires a UI implementation to complete it, however it is provided for use by applications running on the environment managed by the security adaptor.
The overall sequence of events between a user, a security adaptor implementation and the security system is shown in the following diagram:
Figure 21 - Security Adaptor and Security System Event Sequence
2.5.3.1 Change Password
Change password may be called by any application and is accessed by an authenticated (logged in) user. An application facility applications is required to allow the entry of the new password, old password, a password question and a corresponding answer (for retrieval of forgotten passwords). The changePassword message has the following signature:
Type: synchronous
Client sends: changePassword
Contents: PasswordInfo Complex 1
UserID String 1
Passwords Complex 1
NewPassword String 1
OldPassword String 1
PasswordQuestion String 0-1 PasswordAnswer String 0-1 Security: https + auth token
Protocol: https
Client receives: changePasswordResults
Contents: PasswordChangeDetails Complex 1
UserID String 1
ChangeStatus String 1
Success #enum
or Failure #enum
FailureReason String 0-1
or: authFault Patterns Covered:
Synchronous Services changePassword service is synchronous Component uses component services to access database Serial Service Orchestration executes services in sequence with control
flow
The process executed for this service is outlined in Figure 22 - Security Adaptor Change Password Process.
2.5.3.2 Check Authenticated
Check authenticated may be called by any application to verify that an authentication token is valid for a particular user. The token is returned from the authenticate service and should be stored by some mechanism for a particular browser session. Applications should use this service to protect any secure page. The checkAuthenticated message has the following signature:
Type: synchronous
Client sends: checkAuthenticated
Contents: AuthenticationInfo Complex 1
AuthToken String 1
UserID Integer 1
Security: http Protocol: http
Client receives: checkAuthenticatedResults
Contents: AuthenticationDetails Complex 1
AuthenticationStatus String 1
Success #enum
or Failure #enum
Patterns Covered:
Synchronous Services checkAuthenticated service is synchronous Component uses component services to access database Serial Service Orchestration executes services in sequence with control
flow
The process executed for this service is outlined in Figure 23 - Security Adaptor Check Authentication Process.
2.5.3.3 Authenticate
Any application requiring security may provide a log in capability for the user. The authenticate service can be called by any application to verify the identity of a user. The authenticate message has the following signature:
Type: synchronous
Client sends: authenticate
Contents: AuthenticationInfo Complex 1
UserName String 1
Password String 1
Security: https + encryption Protocol: https
Client receives: authenticateResults
Contents: AuthenticationDetails Complex 1
UserID Integer 1
AuthToken String 0-1
or FailureReason String 0-1
Patterns Covered:
Synchronous Services authenticate service is synchronous
Component uses component services to access database Serial Service Orchestration executes services in sequence with control
flow
The process executed for this service is outlined in Figure 24 - Security Adaptor Authenticate Process.
2.5.3.4 Check Authorization
Once a user is authenticated, any application may call check authorization to see if a user has been granted a specific role. This enables applications to customize interfaces and secure functions based on the user’s roles. The checkAuthorization message has the following signature:
Type: synchronous
Client sends: checkAuthorization
Contents: AuthorizationInfo Complex 1
UserID Integer 1
Role Complex 1
ID Integer 1
Security: http + auth token Protocol: http
Client receives: checkAuthorizationResults
Contents: AuthorizationDetails Complex 1
AuthorizationStatus String 1
Success #enum
or Failure #enum
or: authFault Patterns Covered:
Synchronous Services checkAuthorization service is synchronous Component uses component services to access database Serial Service Orchestration executes services in sequence with control
flow
The process executed for this service is outlined in Figure 25 - Security Adaptor Check Authorization Process
2.5.3.5 Get Authorization
Once a user is authenticated, any application may call get authorization to obtain a list of roles that have been granted to that user. This enables applications to customize interfaces and secure functions based on the user’s roles. The getAuthorization message has the following signature:
Type: synchronous
Client sends: getAuthorization
Contents: AuthorizationInfo Complex 1
UserID Integer 1 Security: http + auth token
Protocol: http
Client receives: getAuthorizationResults
Contents: AuthorizationDetails Complex 1
Roles Complex 1
Role Complex 0-*
Name String 1
ID Integer 1
or: authFault
Patterns Covered:
Synchronous Services getAuthorization service is synchronous Component uses component services to access database Serial Service Orchestration executes services in sequence with control
flow
The process executed for this service is outlined in Figure 26 - Security Adaptor Get Authorization Process.
Figure 22 - Security Adaptor Change Password Process
Figure 23 - Security Adaptor Check Authentication Process
Figure 24 - Security Adaptor Authenticate Process
gure 25 - Securit
Fi y Adaptor Check Authorization Process
Figure 26 - Security Adaptor Get Authorization Process
2.6 rovision of Security Services through Interce P pts
ty services are explicitly included in many processes within this specification as ess. There are two main security services currently in use:
Currently, securi steps in the proc
and
There are many other potential services that could be added, most notable encryption ecryption, logging and auditing. Adding additional services to each process, complete with
/
e
ieve this in SOA is an intercept. As the name suggests it sits between ing the message and taking some action upon ncentrate on the business purpose of their rocess. Security services are added during administration – as a rule, developers should not need to code security into the application.
This does not change the security requirements of processes, but changes the way these requirements are added to the process. The following diagram shows how processes engage security services without intercepts:
d
failure handling could lead to unwieldy and complex process definitions. The recommended approach here is to take a page out of the Aspect Oriented Programming (AOP) book. Each of these features is a “cross-cutting concern” – an aspect of many processes that needs to b applied in a consistent way.
The pattern used to ach
the service consumer and the provider, intercept it. In the way, the service provider can simply co p
Figure 27 - Security without Intercepts
For every service provided by the security system (this is not restricted to message based e, or deal with encryption are also services) there is a n a process. Each node needs to be included explicitly in the services, utilities that sign a messag
orresponding potential node withi c
process at the correct point, and failure of the service and corresponding fault response needs to be encoded specifically. This leads to a process design, and resulting implementation that is difficult to follow and hard to maintain for many processes.
The following diagram shows the same process with and without security interception:
definition would grow if more services were included, the developer of this process about security, and every process would need to be changed if security requirements changed.
Figure 28 - Sample Explicit Security Process Figure 29 - Sample Intercepted Security Process
The process
needs to be concerned
By introducing security through interceptors, the model changes. The security aspects of an application are applied by an administrator by setting properties. For example, a process can
e flag such that it requires authentication, the message is signed and encrypted and access be lo hows how security is simplified through interceptors.
b
should gged. The following diagram s
Figure 30 - Security with Interceptors
at th th the consumer (send) and provider (receive) ends a service invocation can be marked as requiring ls to use), needing to be signe pted or that the provider end, the service can be marked as re iring
it requires decryption or that use of the servi should
ndent of security. No additional explicit process nodes done outside of the process a
specifi aspects of security within the proc odel epted aspects in a final implementation.
ote th e message is intercepted at bo N
of the interaction. At the consumer end, authentication (specifying the credentia
eds to e
d or encry invocation ne be logged. At th
igned,
qu ce authentication, that it should be s
be logged.
In this way, processes become indepe are required and fault handling can be
vided s
nd in a standard way across all pro ervices.
Although the cation explicitly defines some c
ess m diagrams, these should ideally be treated as inter
3 PROVISION OF A PRODUCT DATA SERVICE 3.1 Overview
ike terpris as grown over time. ult, da
ert data sources. O icular c , in this
are two data sourc ng information s. The abases, but have very different schema
he r database duct information and was efore the Web
y of dis newer database w lt to con more
n about pr nd handle chang gemen
he Product Data Service provides a single point of entry into both data sources. This allows L many en es, our example enterprise h As a res ta p aining to many similar entities is present in many ne part ase specification, is that of product information. There es containi
about product y are both relational dat .
T olde contains only basic pro in place b
became a wa tributing product catalogs. The as bui tain informatio oducts, to include web images a e mana t.
T
systems to obtain product information from both places using a single query mechanism. The data service also adds defaulted information into the returned data structures when that information is not present in the old system.
3.2 Data Structures
The older database has the following structure:
Figure 31 - Old Product Database Structure
his resents a tree of ca ch category having associated pro n.
ach product belongs to a category and has associated with it keywords present in a single
The
pro cture:
rep tegories, ea
T duct informatio
E
column entry. Additional information was added to the product in the form of an item that included its price, cost to make and status that determined its availability. This was then further extended by adding additional inventory information in an additional table.
new product database was part of an eCommerce initiative, but for legacy reasons older ducts cannot be migrated into it. This database has the following stru
Figure 32 - New Product Database Structure
The new database has a slightly different structure and contains much more information. There still a tree of categories, but now products can belong to more than one category by way of
e. Product keywords are now stored in a separate table to fa oduct and category tables contain ana ment
bout th d and modified them and also image and pag
products on the Web. Inventory information is not present in to the Supply Chain system and can be accessed through a ervice call.
is
the product/category many to many tabl
cilitate faster searching. The pr change m ge
information a e users that create e
information used to display these this database as it now belongs s
3.3
data se vices to query returned list ucts o ategories informa cts or categories. These a the following Services
The product rvice provides four ser s of prod r c and detailed tion about single produ
iagram:
re shown in d
Figure 33 - Product Data Services
These services may be invoked freely by any corporate portal (Employee, Sales, or Customer) or any other corporate system, providing maximum reuse. For the purpose of this specification, however, a particular consumer is not defined.
3.3.1 Get Categories
The getCategories service returns a list of categories based on query criteria. Categories can be queried based on a parent id, product id or partial name. It has the following signature:
Type: synchronous
Client sends: getCategories
Contents: CategoryQuery Complex 1 ParentCategoryID String 0-1
or ProductID String 0-1
or NameContains String 0-1
Security: none Protocol: http
Client receives: categoriesResults
C Complex 1 Complex 0-*
ID String 1
Name String 1
ince the two databases have different category id structures and the old database does not
. Generate a unique Category/ID between databases. This could be something like OLD-{CATID} and NEW-{CATEGORY_ID}. This id should be used in future queries as the parent id or category id in product searches.
d on a product id that has been generated in product searches
name for the old database gory
returns the details of a single category based on the unique generated ins more detailed category information, as well as references d any child categories. It has the following signature:
lient sends: getCategory
Contents: Category Complex 1
ID String 1
Security: none Protocol: http ervice receives: categoryResult
Contents: Category Complex 1
ID String 1
Name String 1
ShortDescription String 0-1
LongDescription String 0-1
LargeImageUrl String 1
LargeImageAltText String 1
ParentCategory Complex 0-1
ID String 1
Name String 1
ShortDescription String 0-1
SmallImageUrl String 1
SmallImageAltText String 1
ChildCategories Complex 1
Category Complex 0-*
ID String 1
Name String 1
ShortDescription String 0-1
SmallImageUrl String 1
SmallImageAltText String 1
ontents: ListOfCategories Category
ShortDescription String 0-1
SmallImageUrl String 1
SmallImageAltText String 1
S
contain image information, the service will have to perform the following tasks:
1
2. Retrieve categories base using a similar mechanism
3. Retrieve Name and Short Description from both databases
4. Retrieve image information from the new database, but generate image URLs and alt text based on category
3.3.2 Get Cate
The getCategory service category id. The response conta to the parent category, if any, an
Type: synchronous
C
S
As with the getCategories service, this service also needs to deal with aggregation and creation of default data for image URLs. The ID passed into this service is of the format of the unique category id as specified in the previous section.
3.3.3 Get Products
The getProducts service returns a list of products based on query criteria. Products can be queried based on any combination of category id, product name, keywords, and minimum / maximum price. This service has the following signature:
Type: synchronous
Client sends: getProducts
Contents: ProductQuery Complex 1
CategoryID String 0-1
NameContains String 0-1
Keywords String 0-1
Keyword String 0-*
Client receives: productsResults
Contents: ListOfProducts Complex 1
Product Complex 0-*
ID String 1
Name String 1
ShortDescription String 0-1
allImageUrl String 1
o perform the following tasks:
nd NEW-{SKU}. This id should be used in future queries to get product e a list of categories that product belongs to.
scription from both databases
he getProduct service returns details about a particular product based on the unique
Client sends: getProduct
Complex 1
Sm
SmallImageAltText String 1
Price Decimal 1
Since the two databases have different product id structures and the old database does not ontain image information, the service will have t
c
1. Generate a unique Product/ID between databases. This could be something like OLD-{PRODUCTID} a
details or retriev
2. Retrieve products based on a category id that has been generated in category searches using a similar mechanism
3. Retrieve Name and Short De
4. Retrieve image information from the new database, but generate image URLs and alt text based on category name for the old database
3.3.4 Get Product T
generated product id. This service has the following signature:
Type: synchronous
Contents: Product
Complex 1
service also needs to deal with aggregation and creation
s, a
Type: synchronous
Client sends: getInventory
Contents: Product Complex 1
SKU String 1
Security: http Protocol: http
Client receives: inventoryResult
Contents: Product Complex 1
SKU String 1 Client receives: productResult
Contents: Product
ShortDescription String 0-1 LongDescription String 0-1
LargeImageUrl String 1
LargeImageAltText String 1
Price Keywords
Category Complex 0-*
ID String 1
Name String 1
Inventory Integer 1
ShippingDate Date 1
As with the getProducts service, this
of default data for image URLs. The ID passed into this service is of the format of the unique product id as specified in the previous section.
The Inventory for old products is retrieved directly from the inventory table. For new product ervice provided by the Supply Chain System is used to obtain inventory.
s
This service has the following signature:
EarliestShipDate Date
4 CONSTRUCTION OF AN EMPLOYEE PORTAL 4.1 Overview
The Employee Portal is an example of a Service Consumer. It is a Web site that enables an umber of operations supporting their job. Each operation is backed by ervices. It is a requirement that the Employee Portal does not have direct access to any of the employee to carry out a n
s
data stores providing information or supporting operations the employee can carry out.
Instead, the portal is comprised of several self-contained portlets each of which retrieve information and carry out operations through back-end services based on user interaction.
Figure 34 - Example Employee Portal
ws an he Self-Help section is shown for
om ness, but is ecification. The portions of the port d in tion are
. Task List 4.
e Revie
of the use-c de up of a number of operations that are provided by services.
e interaction the user will have with the portal.
Figure 34 sho example Employee Portal. T
c plete outside the scope of this sp al define
this specifica : 1. Login
2
3. Employee Lookup Expense Report Process 5. Employe w process Each se ases is ma The operations somewhat mirror th
These are summarized in the following Use Case diagram:
Figure 35 - Employee Portal Use Cases
artments, Get Transactio nd Employee) are services. That is they are self contained atomic services that do not requir nal c nd do n item. Other operations (such as Submit Report r P Review) e part of a long-lived transaction ca ate
h of the use-cases and the operations that they contain.
rtal should utilize the services provided by aptor c ortal as defined in section 2.5.3. At the minimum this
e four
king of aut requiring login before ac allowe ision of logi
ision of a ch nism
particular functio
he rity adapto l depend on inherent security f
he por tion features such as saving a password, or personalization may be incorporated but are outside the scope of this specification.
Some of these operations (such as Get Dep ns or Fi business
pro essing a ot change the state of some
e additio o rocess are workflow services that a
informatio itional backend processing.
r rrying st
n and add
The following sections detail eac 4.2 Authenticate
The Authentication mechanism for the Employee Po a security ad onfigured for the p
ovid
should pr capabilities:
1. Chec hentication for all access cess is d 2. Prov n / logout functionality
3. Prov ange password mecha
4. Utilization of users roles to determine access to nality il
T secu r implementation for the portal w available on t tal platform. Additional customiza
eatures
4.2.1 Check Authentication
Whenever a user attempts to access the Employee Portal or one of its internal pages the Portal should check to see if the user is authenticated. Some mechanism should be provided to
Whenever a user attempts to access the Employee Portal or one of its internal pages the Portal should check to see if the user is authenticated. Some mechanism should be provided to