system design specification€¦ · web viewsystems analysis & design: system design...

University of Edinburgh_______________________________________________________________________________________________________

Stage: Systems Analysis and Design

System Design Specification

Migrate IDM to Oracle SOA Suite 11g and Upgrade Grouper

Iteration 1 – Outbound processing

Communication

COM007

AP23-001

Document Version: 1.0

Date: 17/06/2013___________________________________________________________________________________

Information Services - Template Revised March 2011

University of Edinburgh_______________________________________________________________________________________________________

___________________________________________________________________________________

Information Services - Template Revised March 2011

Systems Analysis & Design: System Design Specification Iteration 1 – Outbound processing[Version: 1.0]_______________________________________________________________________________________________________

Contents

1 DOCUMENT MANAGEMENT..................................................................51.1 Contributors.....................................................................................................51.2 Version Control................................................................................................5

2 OVERVIEW...............................................................................................6

3 DEVELOPMENT TOOLS AND STANDARDS.........................................73.1 Development Tools...........................................................................................73.2 Development Standards...................................................................................7

4 SYSTEM PROCESSES............................................................................84.1 Database Changes............................................................................................8

4.1.1 Table changes.................................................................................................84.1.2 PL/SQL Changes............................................................................................8

4.2 Java web service changes.................................................................................84.3 SOA changes.....................................................................................................94.4 IDM UI............................................................................................................21

4.4.1 UI Alerts.......................................................................................................234.4.2 User administration......................................................................................244.4.3 Service contact administration.....................................................................274.4.4 Service administration..................................................................................31

5 VRS DECOMMISSIONING WORK.........................................................35

6 UNIT TESTING.......................................................................................366.1 SOA Test Suites..............................................................................................36

6.1.1 Test Name....................................................................................................37

7 USER INTERFACE.................................................................................387.1 Transactional Interface.................................................................................38

7.1.1 MyEd Interface.............................................................................................38

7.2 Reporting Interface........................................................................................38

8 APPLICATION SECURITY.....................................................................398.1 Authentication................................................................................................39

8.1.1 Oracle SOA and Java web services..............................................................398.1.2 IDM UI.........................................................................................................39

8.2 Authorisation..................................................................................................39

___________________________________________________________________________________

of 52


8.2.1 Oracle SOA and Java web services..............................................................398.2.2 IDM UI.........................................................................................................39

8.3 Business Objects.............................................................................................40

9 DATABASE DESIGN..............................................................................419.1 UI Tables.........................................................................................................429.2 Service Tables.................................................................................................439.3 Notification tables...........................................................................................46

10 APPLICATION INTERFACES............................................................50

___________________________________________________________________________________

of 52


1 Document ManagementWhen completing this document, please mark any section that is not required as ‘N/A’. A brief description of why the section is not required should also be included.

1.1 Contributors

Please provide details of all contributors to this document.

Role Unit NameSystems Analyst Designer (Owner)

IS Applications Development Team

Richard GoodMichael Sun

Development Lead

IS Applications Development Team

Richard Good

Project Manager IS ApplicationsBusiness Services

Stephen Conlon

Analyst Developer IS Applications Development Team

Michael Sun

1.2 Version Control

Please document all changes made to this document since initial distribution.

Date Version Author Section Amendment17/06/13 1.0 RG All Initial Structure, Overview, UI and DB Spec16/08/13 1.0 MS 4.3 SOA Change29/08/13 1.0 MS 4.3 Remove EDN17/09/13 1.0 MS 4.4 Various UI Changes

___________________________________________________________________________________

of 52


2 OVERVIEW

This System Design Specification details the changes required for Iteration 1 of the COM007. For a general overview of this project, the iterations and others, refer to the High Level Design document.

This iteration focuses on the outbound “push” processing side of the Identity Management System. The design will focus on the following improvements:

The design is split into sections which broadly speaking cover the different application technologies involved:

Database changes Java Web Service changes SOA SCA applications Spring Java UI application Cold Fusion VRS Decommissioning

___________________________________________________________________________________

of 52

Queue Management Error Handling Performance

Service Notification

control

New administrative User Interface

https://www.projects.ed.ac.uk/webfm_send/1826


3 DEVELOPMENT TOOLS AND STANDARDS

3.1 Development Tools

SOA 11g(BPEL, Mediator, EDN) Java Cold Fusion XML Oracle 11g

3.2 Development Standards

Tick the appropriate box to indicate the standards being followed for this application:

Standard √ indicates complianceDatabase Design √SOA Development Standards √Cold Fusion √Java √Uportal Development n/aAccessibility √Web Style Standards √Supported Web Browsers √

___________________________________________________________________________________

of 52

Systems Analysis & Design: System Design Specification Upgrade of Oracle SOA Suite[Version: 1.0]_______________________________________________________________________________________________________

4 SYSTEM PROCESSES

4.1 Database ChangesNOTE: The database changes must be done prior to any other build work.

4.1.1 Database patching automation

In order to control what is applied to the various IDM schemas, patching automation will be introduced. In this way only code applied via the IS Apps SVN repository will be applied to the database, and will therefore be auditable and properly managed.

4.1.2 Table changes

All tables must be created or altered as per Section 8.

4.1.3 PL/SQL Changes

All packages which reference tables altered in Section 4.1.1 must be updated.

4.2 Java web service changesThe Java Web Service (wsIDMXmlProcessHandlerService) should be moved over to the SOA infrastructure incorporate with new changes in service definition table:

Notification Configuration CommentsGEN_NOTIFICATIONS Whether to generate notifications for the serviceGEN_INSERT Whether to generate insert notificationsGEN_UPDATE Whether to generate update notificationsGEN_DELETE Whether to generate delete notificationsGEN_IDENTITIES Whether to generate identity notificationsGEN_GROUPS Whether to generate group notificationsGEN_ENTITLEMENT Whether to generate entitlement notifications (for services

other than this one)

Alongside change type I, U, D, fine-grained notification types will also be inserted in notification queue table:Notification Configuration CommentsM30_SpecialCase_hasEverBeenNotified In case the service receives an update

notification but never received an Insert first. M31_Identity_creation_or_38_Returning_identity New identity or returning identity creationM32_Identity_suspension Identity suspensionM33_Identity_affiliation_change Identity affiliation change, e.g. affiliation end

date updatedM33_Identity_data_change Identity data change, e.g. address changesM34_Identity_entitlement_change_ADDITION New entitlement added for identityM34_Identity_entitlement_change_DELETIONM35_Identity_affiliation_addition

Entitlement removed for identityNew affiliation for identity, e.g. a student affiliation is created for an applicant

___________________________________________________________________________________

of 52


M36_Identity_affiliation_status_changeM37_Identity_deletion

Affiliation status change, e.g. Active to ExpireIdentity deletion

4.2.1 Student Discussion Forums IDM connectorStudent Discussion Forums IDM connector will be converted into a Type 3 connector, more information can be found at Section 4.3.2.4 Downstream Connector Processing (v3) (Ref 4)

4.2.2 MyEd IDM Connector

The connector should be moved over to the SOA 11g infrastructure as-is.

The column IDENTITY_WS_URL in IDM_SERVICE_DEFINITIONS must be updated to the new endpoint.

4.2.3 Wiki IDM Connector

The connector should be moved over to the SOA 11g infrastructure with environmental variables separated to a property file as belowconfluence.propertiesevn=DEVconfApiEndPoint=https://www-dev.wiki.ed.ac.uk/rpc/soap-axis/confluenceservice-v2wikiUserName=wikiloadwikiPassword=infokeep

The column IDENTITY_WS_URL in IDM_SERVICE_DEFINITIONS must be updated to the new endpoint.

___________________________________________________________________________________

of 52


4.3 SOA changes

4.3.1 Overview

___________________________________________________________________________________

of 52

Notification Queue Poller

V1 Legacy Connector

V2 JavaWS Connector

ITI Unix Connector

NOTIFICATION_QUEUE

4

V3 SOA ConnectorForum

MyEd JavaWSCCD JavaWSWIKI JavaWSConnectors

Forum BPEL process

Notification XML:1. ID2. Change Type3. Source4. Service ID5. XML

1

2 3

NOTIFICATION _ INPROGRESS

NOTIFICATION_ARCHIVE NOTIFICATION_ERROR

IDM_SERVICE_DEFINITIONS

1. On receive notification, insert it into

NOTIFICATION_INPROGRES

2. Determine which downstream connector to handle notification

3. Invoke downstream connector

4. Receive process result; update status and error info (if any)

processNotificationHandler


4.3.2 SOA Process Flow

A typical running scenario is outlined below, items highlighted in bold are discussed in details in later sections.

The sample scenario is one MyEd Student Update Notification and one Forum Staff Insert notification are inserted into notification queue, the idmOutboundNotificationProcess processes as the following:

Notification Queue Polling (Ref 1)One MyEd notification and one Forum notification are inserted into notification queue IDM_NOTIFICATION_QUEUE; NotificationQueuePoller_DBAdaptor picks up these two notifications, and passes to processNotificationHandler BPEL process; these two notifications are deleted from IDM_NOTIFICATION_QUEUE immediately.

processNotificationHandler onReceive Notification (Ref 1)After polled from IDM_NOTIFICATION_QUEUE, notifications are converted into xml as below and passed onto processNotificationHandler, on processNotificationHandler receive; they are immediately inserted into IDM_NOTIFICATION_INPROGRESSMyEd Notification Forum Notification <notification> <notification><id>f81d4fae-7dec-11d0…</id> <id> a765-00a0c91e6bf6…</id> < changeType >U< /changeType > < changeType >I< /changeType >< source >student< /source > < source >staff< /source >< serviceId >505</ serviceId > < serviceId >200</ serviceId >< xml >…</ xml > < xml >…</ xml >< dateCreated >2013-08-16</ dateCreated > < dateCreated >2013-08-16</ dateCreated >< sourceChangeId >sd56…</ sourceChangeId > < sourceChangeId >8a9df…</ sourceChangeId > < idstoreUid >s0347553</ idstoreUid > < idstoreUid >hsun1</ idstoreUid </ notification > </ notification >___________________________________________________________________________________

of 52


processNotificationHandler Processing (Ref 2)Notification will be examined, based on serviceId, processNotificationHandler determines which downstream handler (processNotificationV1V2 or processNotificationForum) should handle this notification and invoke it accordingly.

Downstream Connector V1, V2 (Ref 3)processNotificationV1V2 BPEL receives MyEd notification passed in by processNotificationHandler and call idmNotificationSenderWS to push the notification to MyEd downstream connector.

Suppose MyEd downstream connector is offline due to network issues, while processNotificationV1V2 is calling idmNotificationSenderWS, it also starts an internal timer, if the MyEd connector cannot complete within time limit, onAlarm operation will be triggered, as the notification has change type U and the notification type is M33_Identity_data_change, the operation will be retried once. Suppose on the second try, MyEd connector returns success, the status of this MyEd notification in IDM_NOTIFICATION_INPROGRESS is updated as Completed.

Downstream Connector V3 (Ref 4)processNotificationForum BPEL receives Forum notification passed in by processNotificationHandler and processes this notification as a series of BPEL operations. Suppose the notification failed to be processed due to data error, the status of this Forum notification in IDM_NOTIFICATION_INPROGRESS is updated to Error and detailed error messages is inserted into IDM_NOTIFICATION_ERROR table.

Downstream Connector Processing Support Util processNotificationHandler, processNotificationV1V2 and processNotificationForum should be defined as internal process only, they should not have an exposable end point, by doing so, it secures the downstream connector from unauthenticated/unauthorised access.

processNotificationSupportUtil is developed to act as a testing/debug/support util, it has an exposable end point and can make invocation to processNotificationV1V2 and processNotificationForum through weblogic interface or SoapUI.

processNotificationSupportUtil will be protected by authentication/authorization policy, so only by authorised user can make such invocation.

___________________________________________________________________________________

of 52


4.3.2.1 Notification Queue Polling (Ref 1)

A DBAdaptor will be constantly polling new notifications from IDM_NOTIFICATION_QUEUE at certain frequency; it is defined as

DBAdaptor name: notificationQueuePoller_DBAdapterPolling Source: IDM_NOTIFICATION_QUEUEAfter Read: Delete row(s) that were readPolling Frequency: 5 secondsDatabase Rows per XML Document: 1 (to be confirmed)Database Rows per Transaction: 1 (to be confirmed)

Notification Queue (Row) Schema:

___________________________________________________________________________________

of 52


After a new notification is picked up by DBAdaptor, it will be forwarded processNotificationHandler BPEL process; the notification will be deleted immediately.

4.3.2.2 processNotificationHandler (Ref 2)

processNotificationHandler manages notification execution flow, namely, mange notification flow between IDM_NOTIFICATION_QUEUE and IDM_NOTIFICATION_INPROGRESS, determines/invokes downstream connector, update notification status etc., processNotificationHandler is defines as

BPEL Process Name: processNotificationHandlerNamespace: http://xmlns.ed.ac.uk/idm/idmOutboundNotificationProcess/processNotificationHandlerService Name: processNotificationHandler_ clientExpose as a SOA service: no

___________________________________________________________________________________

of 52


Process Flow:

receiveInput – insert notification into IDM_NOTIFICATION_INPROGRESS immediately

readServiceDefinition – extract serviceId, read service definition table with readServiceDefinition_DBApator, determine which downstream connector to process this notification, holds ws end point information for later use.

invokeProcessNotificationV1V2 – if the notification should be handled by V1V2 downstream handler, invoke processNotificationV1V2

invokeProcessNotificationForum - if the notification should be handled by V3 forum downstream handler, invoke processNotificationForum

updating notification status – based on result from either processNotificationV1V2 or processNotificationForum, update notification status as Completed or as Error in IDM_NOTIFICATION_INPROGRESS table and in case of Error, also logs error details to IDM_NOTIFICTION_ERROR table.

___________________________________________________________________________________

of 52


4.3.2.3 Downstream Connector Processing (v1, v2) (Ref 3)

Version 1 legacy connector is for support ITI Unix service, Version 2 is for support the other JavaWS services, a BPEL process will be developed to invoking V1, V2 downstream services, the BPEL process is defined as the following

BPEL Process Name: processNotificationV1V2Namespace: http://xmlns.ed.ac.uk/idm/idmOutboundNotificationProcess/processNotificationV1V2Service Name: processNotificationV1V2_ clientInput Schema: as the same as notification queue tableExpose as a SOA service: noType: Asynchronous BPEL Process

___________________________________________________________________________________

of 52


Process Flow:

receiveInput - receive notification from processNotificationHandler invokeidmNotificationSenderWS –invoke idmNotificationSenderWS to

push notifications onAlarm retry – if the change type is U and idmNotificationSenderWS isn’t

able to complete within time limit (i.e. 3 min) as defined in onAlarm operation, retry invoking idmNotificationSenderWS one more time

replyClient – reply processNotificationHandler with result from idmNotificationSenderWS

___________________________________________________________________________________

of 52


4.3.2.4 Downstream Connector Processing (v3) (Ref 4)Version 3 service push model, whereby a service connector is written purely in SOA, we are proposing Discussion Forum as Version 3 connector, it is defined as

BPEL Process Name: processNotificationForumNamespace: http://xmlns.ed.ac.uk/idm/idmOutboundNotificationProcess/processNotificationForumService Name: processNotificationForum _clientInput Schema: as the same as notification queue tableExpose as a SOA service: noType: Asynchronous BPEL Process

___________________________________________________________________________________

of 52


Process Flow: receiveInput – the input contains <sendIdentity> xml, it will be passed in as

string and parsed by parseXML() function to convert it to xml object, after xml object is created, changeType and affilicationType will be extracted, depends on changeType(I, U, D), and affilicationType (STF,STUUG,STUPGT,STUPGR,VSTF,VSTU), further logic is executed accordingly.

changeType I – this indicates the change is an insert, a DBAdaptor will bedeveloped to insert (ID, UUN, FORENAME, SURNAME, FULLNAME, PREFNAME, EMAIL, TYPE) into FORUMS_IDMS_USER_BASE table.

changeType U – this indicates the change is an update, a DBAdaptor will bedeveloped to update (ID, UUN, FORENAME, SURNAME, FULLNAME, PREFNAME, EMAIL, TYPE) in FORUMS_IDMS_USER_BASE table.

changeType D – this indicates the change is a delete, a DBAdaptor will bedeveloped to delete row by ID i.e. eduniidmsid from FORUMS_IDMS_USER_BASE table

response – reply either 200 or 500 to indicates success or failure and also attach error message in case there is a failure

___________________________________________________________________________________

of 52


4.3.2.5 Downstream Connector Processing Support Util (v3) (Ref 4)BPEL Process Name: processNotificationSupportUtilNamespace: http://xmlns.ed.ac.uk/idm/idmOutboundNotificationProcess/processNotificationSupportUtilService Name: processNotificationSupportUtil_clientInput Schema: as the same as notification queue tableExpose as a SOA service: yesType: Asynchronous BPEL Process

___________________________________________________________________________________

of 52


Process Flow:

receiveInput – use SoapUI or weblogic UI to supply service id, change type, notification xml etc.

invoking processNotificationV1V2/processNotificationForum – notification xml will be forward to processNotificationForum/processNotificationV1V2 BPEL processes

This support utility can be enhanced with further notification queue table operations, e.g. reset notification status, move notification xml between queue table, archive table etc. Such utilities will be useful to ease support tasks.

___________________________________________________________________________________

of 52


4.3.2.6 idmNotificationSenderWSidmNotificationSenderWS is a java web service that confirms to the same wsdl which all V1, V2 downstream connectors are developed from. It will be upgraded from existing wsIDMNotificationHandlerService which was developed under ITS029

More information can be found here - https://www.wiki.ed.ac.uk/display/IDM/Downstream+Web+Service+WSDL

4.3.3 10g Deactivation of notification processes

The following SOA processes will be deactivated as part of the implementation of this iteration:

esbIDMNotificationQueueListener bpelIDMNotificationQueueHandler

NOTE: The processes should merely be deactivated, and not removed. In the event of a major problem with the migration to 11g, they can be reactivated to restore service.

4.4 IDM UI

As per the high level design, a new User Interface will be created to begin the migration of IDM related features away from VRS. For this iteration, it will consist of:

IDM UI user and role management Service contact management Service administration (for existing services only)

A Java application will be created to deliver these features, using the following components/frameworks:

Bootstrap – Framework for User Interface presentation Hibernate – Framework for Database persistence Java 1.7 – Java runtime Less – Dynamic stylesheet language Maven 3 – Dependency and build management Spring 3 – MVC framework

4.4.1 Project file structure

The Maven project should have the following structure:

___________________________________________________________________________________

of 52

http://www.springsource.org/documentation

http://maven.apache.org/

http://lesscss.org/

http://www.oracle.com/technetwork/java/javase/downloads/index.html

http://www.hibernate.org/

http://twitter.github.io/bootstrap/


Figure 1. Project file structure

java – All Java source code less – Less CSS compiler files resources – Message property files webapp/images – Any images for the UI WEB-INF – Configuration files for the webapp jsp – View JSPs

4.4.2 Java package structure

The Java application should have the following package structure:

___________________________________________________________________________________

of 52

src/main

java

less

resources

webappimages

WEB-INF jsp

target


Figure 2. Java package structure

controller – Controller classes for the UI dao – Data Access Object interfaces impl - Implemented classes for the DAOs data – Entity classes for interacting with the DB form – Form classes for UI service – Service classes which the controllers will use

4.4.3 UI Alerts

Generic alerts should be added into the UI such that all screens support alert feedback. There should be three types:

Success alerts Warning alerts Error alerts

All alerts must use Spring Messaging, to allow easy changes to messages.

4.4.3.1 Success alerts

___________________________________________________________________________________

of 52

uk.ac.ed.idm

controller

dao impl

data

form

service


Figure 3. Success alert

The success alert must:

Show the word Success Show a message indicating what was successful Allow the user to dismiss the alert message

4.4.3.2 Warning alert

Figure 4. Warning alert

The warning alert must:

Show the word Notification Show a message indicating what was successful Allow the user to dismiss the alert message

4.4.3.3 Error alert

Figure 5. Error alert

The error alert must:

Show the word Error Show a message indicating the error which occurred Allow the user to dismiss the alert message

4.4.4 User administration

___________________________________________________________________________________

of 52


Screens should be set up for the administration of users. The general features are as follows:

It should be possible to add a new user into the system using a set of standard user search criteria

It should be possible to assign and remove roles to a new or existing user It should be possible to completely remove a user from the system. It should only be available to users with the SUPERADMIN role.

NOTE: For details on the required tables, refer to Section 8.1.

4.4.4.1 User search screen

The user should be first presented with a screen to search for a user to administrate:

Figure 6. User search screen

The user should be able to choose a number of options, one of which must be entered:

Surname Forename(s) Preferred Name UUN

___________________________________________________________________________________

of 52


Ref Number Affiliation (dropdown)

4.4.4.2 User search results screen

The screen, when submitted, should perform its search against the IDSTORE_IDENTITY table, and show the results screen.

Figure 7. User admin search results

The search results screen should display a list as per the entered search criteria. The list should contain the following:

UUN – hyperlinked to allow edit of that user Forename(s) Preferred Name Surname

4.4.4.3 User edit screen

Clicking a UUN should take the user to the edit user screen:

Figure 8. Edit user screenshot

The screen must:

___________________________________________________________________________________

of 52


Display which user is being edited clearly Provide checkboxes to assign/un-assign roles Provide the ability to Delete a user Provide the ability to Save the user Provide the ability to Cancel edit mode

Roles and role descriptions should be pulled from IDM_UI_ROLES.

Save must:

Insert the user into IDM_UI_USERS (if it doesn’t already exist). Insert any checked roles into IDM_UI_USER_ROLES for that user Delete any unchecked roles from IDM_UI_USER_ROLES for that user

Delete must:

Provide the user with a confirmation modal before continuing Delete all user roles for that user from IDM_UI_USER_ROLES Delete that user from IDM_UI_USERS

4.4.5 Service contact administration

Screens should be created to allow users to create and administrate service contacts.

Prior to creating these screens, the table IDM_SERVICE_CONTACTS should be updated as per the description in Section 8.1. In addition:

Any existing CONTACT_ID in IDM_SERVICE_DEFINITIONS should be mapped to a MAIL column in IDM_SERVICE_CONTACTS

4.4.5.1 Contact administration page

When accessing the Service Contact screen, the user should first be presented with a choice of editing an existing contact, or creating a new one:

___________________________________________________________________________________

of 52


Figure 9. Contact administration

The screen must:

Show a list of contact names from IDM_SERVICE_CONTACTS, with an option to Edit an individual contact

Show an option to Create a new Contact

4.4.5.2 Contact edit/create screen

When the user selects either create or edit, they should be presented with the first step of the contact edit screens.

___________________________________________________________________________________

of 52


Figure 10. Edit/Create contact

The screen must:

Show all input fields from the table IDM_SERVICE_CONTACTS Provide the option to Save a contact Provide the option to Delete a contact Provide the option to Cancel the process

Delete must:

Provide a confirmation screen which the user must confirm to continue Delete references to that contact from IDM_SERVICE_DEFINITIONS

___________________________________________________________________________________

of 52


Delete that contact from IDM_SERVICE_CONTACTS Provide an alert in the application UI that shows the success or failure of

above

Save must:

Validate that the email is filled in and in the format of an email address Validate that the contact name is filled in Validate that the organisational unit is filled in Provide feedback in the edit screen if any validation fails Insert/Update into IDM_SERVICE_CONTACTS if validation passes Go onto the service selection screen if validation passes

4.4.5.3 Contact service assignment screen

Step 2 of the contact edit screen should allow the user to associate services with the contact.

Figure 11. Step 2 - assign services to contact

The screen must:

Allow the user to see which services (if any) are associated with the contact Select and de-select services for that contact

___________________________________________________________________________________

of 52


Save the selection Skip assignment and return to the contact administration entry screen

Save must:

Update IDM_SERVICE_DEFINITIONS.CONTACT_ID with the MAIL of the contact for any selected services

Update IDM_SERVICE_DEFINITIONS.CONTACT_ID to NULL for any de-selected services

Provide a success or failure alert back to the user

4.4.6 Service administration

Screens should be built for existing service administration.

NOTE: To save on budget, new services will be scripted for now. If the feature to add a new service is required it could be added later.

4.4.6.1 Service selection screen

When entering into the service administration, the user should first be presented with a screen to select a service to edit.

Figure 12. Service selection screen

The screen must:

Show a list of SERVICE_NAME from IDM_SERVICE_DEFINITIONS in a dropdown list

Allow the user to select a service from the dropdown Allow the user to select edit

4.4.6.2 Service edit screen

___________________________________________________________________________________

of 52


Selecting edit should take the user to the service administration screen. The service administration screen is split into the following sections:

Service definition – (details in IDM_SERVICE_DEFINITIONS) Notification settings – (details in IDM_SERVICE DEFINITIONS) Service Eligiblity - (details in IDM_SERVICE_ELIGIBILITIES) Service Group Mappings (details in IDM_SERVICE_TO_GROUP)

The screen must:

Allow the user to view and edit core service definition settings as per above Allow the user to view and change service eligibilities as per above Allow the user to search for and add a group to the service Allow the user to remove assigned groups from the service Allow the user to Save changes Allow the user to Cancel and return to the initial service administration

screen Allow the user to configure if a service is reprovisionable

NOTE: Adding grouper functions such as creating groups, or assigning membership is out-with the scope of the IDM User Interface, and indeed can be performed using the Grouper User Interface.

Figure 13. Service definition edit

___________________________________________________________________________________

of 52


Figure 14. Service eligiblity edit

___________________________________________________________________________________

of 52


Figure 15. Service group edit

___________________________________________________________________________________

of 52


Figure 16. Service add group modal

Add Group must:

Show a warning alert indicating that the group will immediately be applied Allow the user to search for a group to add If add group is selected, insert that group into IDM_SERVICE_TO_GROUP for

that service

Save must:

Validate that all required fields are filled in Show any validation errors to the user as an error alert message If validation is successful, update IDM_SERVICE_DEFINITIONS,

IDM_SERVICE_ELIGIBILITIES, and IDM_SERVICE_TO_GROUP with any required creations/deletions/updates

4.4.6.3 Removing admin user via agingIn case an admin user is leaving, IDM aging process needs to be modified to remove this user from IDM UI user table

IDM aging must:

If an IDM UI Admin user is leaving, aging process ages this user from IDM Removing this user from IDM UI user table

___________________________________________________________________________________

of 52


4.4.6.4 IDM UI user activity loggingTo audit admin user activities, various user operations will be logged.

Logging function must log:

user login create/edit admin user create/edit service edit service notification settings

5 VRS Decommissioning work

Because of the new User Interface specified above, the following features should be removed from VRS:

Service creation Service administration Contact administration

NOTE: All of the above features are held under the Services tab in VRS.

6 Unit testing

6.1 SOA Test Suites

For each of downstream connector, sendIdentity/sendGroup xml will be constructed and embedded as test suites in composite application; the unit test should cover each notification definition - https://www.wiki.ed.ac.uk/display/insite/IDM+Notifications

Identity creation Identity status change (suspension / unsuspension) Identity data change Identity entitlement change Identity affiliation addition Identity affiliation status change Identity deletion Returning identity Group creation Group update Group delete Group membership addition Group membership removal

The following is a list of downstream connector; more connectors will be added while further development is carried out. ___________________________________________________________________________________

of 52


Forum downstream connector MyEd downstream connector Wiki downstream connector CCD downstream connector EASE downstream connector CentralAuth downstream connector

Each unit test will be specified asInput: sendIdentity/sendGroup xml

Output: response code = 200

___________________________________________________________________________________

of 52


Complete set of sendIdentity/sendGroup xml will be added in the following section while further development is carried out.

___________________________________________________________________________________

of 52


USER INTERFACE

6.2 Transactional Interface

This project has no transactional interface to describe.

6.2.1 MyEd Interface

This project delivers no integration with MyEd.

6.3 Reporting Interface

This project will deliver no extra reporting functionality.

___________________________________________________________________________________

of 52


7 APPLICATION SECURITY

7.1 Authentication

7.1.1 Oracle SOA and Java web services

Services will be password protected using either a http token policy (SOA components) or username policy (Java web service).

processNotificationSupportUtil Type: SOA ComponentAuthentication policy: oracle/wss_username_token_service_policy Authorization policy: uoe/idm_notification_queue_authorization

7.1.2 IDM UI

The IDM UI will be Ease protected.

7.2 Authorisation

7.2.1 Oracle SOA and Java web services

For each SOA component, a group will be created in Weblogic, and the group associated with access. In this way, only users added to the group will be allowed access to the individual web service.

Group: idmNotificationQueueGroup

7.2.2 IDM UI

The IDM UI will have three roles:

SUPERADMIN – Super Administrator role with access to all features SERVADMIN – Service level administrators who can perform service functions SYNCUSER – User role will ability to use the sync tool functions

A user can have one or more of the above roles. For details of where and how the roles are stored, refer to Sections 4 and 8.

___________________________________________________________________________________

of 52


7.3 Business ObjectsNo business objects are required.

___________________________________________________________________________________

of 52


8 DATABASE DESIGN

8.1 DB Patching tables

The following new table is required in the IDSTORE schema:

IDSTORE_PATCH_LOG

PATCH_NAME and PATCH_DATE should be the composite primary key Default values for any patch scripts already applied to IDSTORE must be

inserted into the table using SUCCEEDED = ‘Y’ and PATCHED_DURING_RELEASE = ‘1.0.0’

Column Name Datatype DescriptionPATCH_NAME VARCHAR2(250) The name of the patch scriptPATCH_DATE DATE Date the patch was appliedPATCH_SUCCEEDED VARCHAR2(1) Whether the patch was

successfully appliedPATCHED_DURING_RELEASE VARCHAR2(50) Which release the patch

applies toPATCHED_BY VARCHAR2(50) The uun of the account

applying the patchPATCH_FAILURE_CODE VARCHAR2(50) Code for the patch failurePATCH_FAILURE_MESSAGE VARCHAR2(4000) Message describing the patch

failure

The following new table is required in the IDMENGINE schema:

IDMENGINE_PATCH_LOG







failure

The following new table is required in the GROUPER schema:

___________________________________________________________________________________

of 52


GROUPER_PATCH_LOG







failure

8.2 UI Tables

The following new tables are required in the IDMENGINE schema:

IDM_UI_ROLES

ROLE_CODE should be the primary key Default values for the roles defined in Section 7.2.2 should be inserted

Column Name Datatype DescriptionROLE_CODE VARCHAR2(10) The unique ID of the roleROLE_DESCRIPTION NVARCHAR2(255) The description of the role

IDM_UI_USERS

EDUNIIDMSID should be the primary key

Column Name Datatype DescriptionEDUNIIDMSID NVARCHAR2(36) The unique identifier of the UI

user

IDM_UI_USER_ROLES

EDUNIIDMSID and ROLE_CODE should be the composite primary key

Column Name Datatype DescriptionEDUNIIDMSID NVARCHAR2(36) The unique identifier of the UI

userROLE_CODE VARCHAR2(10) The unique identifier of the

assigned role

___________________________________________________________________________________

of 52


IDM_UI_LOGS

DATE_LOGGED should be the primary key

Column Name Datatype DescriptionDATE_LOGGEDEDUNIIDMSID

DATENVARCHAR2(36)

The time of the activityThe unique identifier of the UI user

ACTIVITY VARCHAR2(255) The description of the activity

8.3 Service Tables

The following tables should be altered in the IDMENGINE schema.

IDM_ELIGIBILITIES

NOTE: The eligibility table should be altered as follows, by changing the columns over to VARCHAR2. Keys and indexes should be recreated as-is only if necessary.

Column Name Datatype DescriptionELIGIBILITY_CODEID VARCHAR2(35) The unique Id of the eligibilityELIGIBILITY_CODE VARCHAR2(1) The code for the eligibilityELIGIBILITY_DESCRIPTION VARCHAR2(32) A description for the eligibilityDATE_MODIFIED DATE The last modified date

IDM_SERVICE_SELECTORS

NOTE: The service selector table should be altered as follows, by changing the columns over to VARCHAR2. Keys and indexes should be recreated as-is only if necessary.

Column Name Datatype DescriptionSERVICE_SELECTORID VARCHAR2(35) The unique Id of the selectorSELECTOR_CODE VARCHAR2(3) The code of the selectorSELECTOR_DESCRIPTION VARCHAR2(32) The description of the selectorDATE_MODIFIED DATE The last modified date

IDM_SERVICE_STATUSES

NOTE: The service status table should be altered as follows, by changing the columns over to VARCHAR2. Keys and indexes should be recreated as-is only if necessary.

Column Name Datatype Description

___________________________________________________________________________________

of 52


STATUS_CODE VARCHAR2(1) The code of the statusSTATUS_DESCRIPTION VARCHAR2(16) The description of the statusDATE_MODIFIED DATE The last modified date

IDM_SERVICE_CONTACTS

NOTE: The service contact table should be altered as follows, with any duplicate data items removed prior to amending the columns. The primary key should be dropped and recreated.

MAIL should be the primary key

Column Name Datatype DescriptionMAIL NVARCHAR2(128) The email address of the

contactCONTACT_NAME NVARCHAR2(128) The name of the contactCONTACT_DESCRIPTION NVARCHAR2(255) The (optional) description of

the contactTEL_NO NVARCHAR2(16) Telephone number of the

contactORG_UNIT NVARCHAR2(8) Organisational Unit of the

contactDATE_MODIFIED DATE Date last modified

IDM_SERVICE_DEFINITIONS

NOTE: The service definition table should be altered as follows. Any new settings should default to Y.

SERVICEID should remain the primary key Fields have changed from NVARCHAR2 to VARCHAR2, they must be altered

as per below LEGACY_CALLER should be renamed CALLER_VERSION, with Y mapped to 1,

and N mapped to 2 CHANGE_INSERT should be renamed to PUSH_INSERT CHANGE_UPDATE should be renamed to PUSH_UPDATE CHANGE_DELETE should be renamed to PUSH_DELETE

Column Name Datatype DescriptionSERVICEID

SERVICE_NAME

VARCHAR2(35)

VARCHAR2(128)

The unique identifier for the serviceThe name of the service

SERVICE_DESCRIPTION VARCHAR2(255) The description of the serviceSERVICE_KEY VARCHAR2(255) The unique GUID key for the

serviceGEN_NOTIFICATIONS VARCHAR2(1) Whether to generate

notifications for the serviceGEN_INSERT VARCHAR2(1) Whether to generate insert

notificationsGEN_UPDATE VARCHAR2(1) Whether to generate update

notifications

___________________________________________________________________________________

of 52


GEN_DELETE VARCHAR2(1) Whether to generate delete notifications

GEN_IDENTITIES VARCHAR2(1) Whether to generate identity notifications

GEN_GROUPS VARCHAR2(1) Whether to generate group notifications

GEN_ENTITLEMENT VARCHAR2(1) Whether to generate entitlement notifications (for services other than this one)

PUSH_ENABLED VARCHAR2(1) Whether push is enabledWS_USERNAME VARCHAR2(20) The web service usernameWS_PASSWORD VARCHAR2(20) The web service passwordIDENTITY_WS_URL VARCHAR2(255) The identity web service URLGROUP_WS_URL VARCHAR2(255) The group web service URLPUSH_INSERT VARCHAR2(1) Whether to push insert

notificationsPUSH_UPDATE VARCHAR2(1) Whether to push update

notificationsPUSH_DELETE VARCHAR2(1) Whether to push delete

notificationsSERVICE_STATUS VARCHAR2(1) The status code of the serviceCALLER_VERSION VARCHAR2(35) Version of the notification

callerSERVICE_CODE VARCHAR2(8) The unique code of the serviceDATE_MODIFIED DATE Date last modifiedVERBOSE_AGING

REPROVISIONABLE

CONTACT_ID

VARCHAR2(1)

VARCHAR2(1)

NVARCHAR2(128)

A flag column to determine if service should be notified about changes to all affiliation statusesIf the service can be re-provisionedContact email, map to service contact table

IDM_SERVICE_ELIGIBILITIES

NOTE: The service eligibility table should be altered as follows, by changing the columns over to VARCHAR2. Keys and indexes should be recreated as-is only if necessary.

Column Name Datatype DescriptionELIGIBILITYID VARCHAR2(128) The unique ID of the eligibilitySERVICEID VARCHAR2(35) The unique Id of the serviceELIGIBILITY_CODEID VARCHAR2(1) The code for the eligibilityCHARGEABLE VARCHAR2(1) Whether the eligibility is

chargeableSELECTABLE_BY VARCHAR2(3) Who can assign identities for

that eligibilityAFFILIATION_GROUPID VARCHAR2(40) The unique identifier of the

affiliation group

IDM_SERVICE_TO_GROUP

___________________________________________________________________________________

of 52


NOTE: The service group table should be altered as follows, by changing the columns over to VARCHAR2. Keys and indexes should be recreated as-is only if necessary.

Column Name Datatype DescriptionSERVICEID VARCHAR2(35) The unique Id of the serviceGROUP_ID VARCHAR2(40) The unique identifier of the

groupDATE_MODIFIED DATE The last modified date

8.4 Notification tables

The following tables should be altered in the IDMENGINE schema.

IDM_NOTIFICATION_QUEUE

NOTE: The notification queue table should be altered as follows by changing the columns over to VARCHAR2, changing the XML data type to NCLOB, and adding new columns to track dates at which the notification changed. Keys and indexes should be recreated as-is only if necessary.

Column Name Datatype DescriptionCHANGE_ID VARCHAR2(32) The unique ID for the

notificationCHANGE_TYPENOTIFICATION_TYPE

VARCHAR2(1)VARCHAR2(50)

The type of changeFine-grain type of notification

SERVICE_ID VARCHAR2(35) The unique ID for the serviceSOURCE VARCHAR2(50) The source of the changeXML NCLOB The XML notificationSTATUS_CODE VARCHAR2(1) The status of the notificationERRCOUNT NUMBER(38,0) The count of errors which

occurred with this notificationDATE_CREATED DATE The date the notification was

generatedDATE_SENT DATE The date the change was sent

to the serviceDATE_APPLIED DATE The date the change was

appliedDATE_MODIFIED DATE The date the notification was

last updatedSOURCE_CHANGE_ID VARCHAR2(32) The unique ID of the change in

IDM_PROCESS_QUEUENOTIFICATION_PRIORITY NUMBER(18,0) Integer value containing the

priority of the notificationPUSH_TO_SERVICE VARCHAR2(1) Whether the notification is to

be pushed to the serviceIDSTOREUID NVARCHAR2(64) The UUN to which the

notification relates

___________________________________________________________________________________

of 52


IDM_NOTIFICATION_INPROGRESS

NOTE: The notification in progress table should be altered as follows by changing the columns over to VARCHAR2, changing the XML data type to NCLOB, and adding new columns to track dates at which the notification changed. Keys and indexes should be recreated as-is only if necessary.





SERVICE_ID VARCHAR2(35) The unique ID for the serviceSOURCE VARCHAR2(50) The source of the changeXML NCLOB The XML notificationSTATUS_CODE VARCHAR2(1) The status of the notificationERRCOUNT NUMBER(38,0) The count of errors which






IDM_PROCESS_QUEUENOTIFICATION_PRIORITY NUMBER(18,0) Integer value containing the

priority of the notificationPUSH_TO_SERVICE VARCHAR2(1) Whether the notification is to

be pushed to the serviceIDSTOREUID NVARCHAR2(64) The UUN to which the


IDM_NOTIFICATION_ARCHIVE

NOTE: The notification archive table should be altered as follows by changing the columns over to VARCHAR2, changing the XML data type to NCLOB, and adding new columns to track dates at which the notification changed. Keys and indexes should be recreated as-is only if necessary.





SERVICE_ID VARCHAR2(35) The unique ID for the service

___________________________________________________________________________________

of 52


SOURCE VARCHAR2(50) The source of the changeXML NCLOB The XML notificationSTATUS_CODE VARCHAR2(1) The status of the notificationERRCOUNT NUMBER(38,0) The count of errors which






IDM_PROCESS_QUEUEIDSTOREUID NVARCHAR2(64) The UUN to which the


IDM_NOTIFICATION_ERRORS

NOTE: The notification error table should be altered as follows by changing the change ID column over to VARCHAR2, and changing the XML data type to NCLOB.

An Index should be created on the column CHANGE_ID


notificationERROR_DATETIME DATE The date the notification was

generatedERROR_CODE NVARCHAR2(100) The error codeERROR_DESCRIPTION NVARCHAR2(2000) The error description

___________________________________________________________________________________

of 52


IDM_NOTIFICATION_KPI_VNOTE: The notification kpi view will union all data from IDM_NOTIFICATION_QUEUE, IDM_NOTIFICATION_INPROGRESS, IDM_NOTIFICATION_ARCHIVE, IDM_NOTIFICATION_ERROR table, it is defined as


notificationCHANGE_TYPE VARCHAR2(1) The type of changeSERVICE_ID VARCHAR2(35) The unique ID for the serviceSOURCE VARCHAR2(50) The source of the changeXML NCLOB The XML notificationSTATUS_CODE VARCHAR2(1) The status of the notificationERROR_DATETIME DATE The date the notification was

generatedERROR_CODE NVARCHAR2(100) The error codeERROR_DESCRIPTION NVARCHAR2(1000) The error description

SOURCE_CHANGE_IDIDSTOREUID

DATE_APPLIED

VARCHAR2(32)NVARCHAR2(64)

DATE

The unique ID of the change in IDM_PROCESS_QUEUEThe UUN to which the notification relatesThe date the change was applied

DATE_MODIFIED DATE The date the notification was last updated

DATE_CREATED DATE The date the notification was generated

DATE_SENT DATE The date the change was sent to the service

___________________________________________________________________________________

of 52

UI

IDM DB

EUGEX DB

IDM Diff SOA Web Service


9 APPLICATION INTERFACES

9.1 IDM UI

The IDM UI interfaces with the following:

Figure 17. UI interfaces

IDM DB – For service, user, role and identity information EUGEX DB – For applicant, student, course and programme information IDM Diff SOA Web Service – For generating notifications when running the

Student Sync Tool

___________________________________________________________________________________

of 52

system design specification€¦ · web viewsystems analysis & design: system design...

Documents