SSAM

1
SSAM

• Server Service Account Management Overview

2
Contents

• About the University of Saskatchewan
• Goals of SSAM
• Where we came from
• Where we are now
• Eligibility Processing (with an example)
• Functional Features
• Design Considerations
• Security
• SSAM compared to the Educause Campus Architecture
  and Middleware Planning (CAMP) model
• Impacts on institutional processes
• Some Statistics
• Future Directions

3
About the University of Saskatchewan

• Offers 58 degrees, diplomas, and certificates in
  over 100 disciplines.
• 15 colleges, 7 affiliated, federated and virtual
  colleges, 7 satellite sites.
• 7,500 Faculty and Staff.
• 19,000 degree students (regular terms), 7800
  students in the summer terms.

From http//www.usask.ca/uofs/fact_sheet.html
4
U of S Technical Infrastructure

• Sun Solaris servers
• Linux servers
• W2K3 Active directory and Windows servers
• SCT Luminis portal
• WebCT and In-House learning management systems
• Banner Student and Finance (as of April 2005,
  in-house systems prior to that)
• Peoplesoft HR Payroll
• In-house systems for Advancement, Name and
  Address, Account Provisioning (SSAM).
• Primarily Oracle DBMS

5
Goals of SSAM

• Goal In an auditable secure manner, use
  software to manage IT services.
• Eligibility (authorization for access to
  services)
• Reduce effort and elapsed time in getting
  services setup for a person.
• Easy Password Synchronization
• Consistent Interface to system level services
  (such as increasing quotas) across multiple
  hardware server platforms

6
Some Terminology

• Service A service managed by SSAM. (Login,
  role, group, access to a web page, etc.)
• Service Instance A record of a person having a
  service.

7
Where we came from

• Little centralization.
• Multiple interfaces to provide support to
  multiple systems.
• 24 hour turnaround for account creation.
• Limited or no audit trail.
• System administrators were spending too much time
  managing individual accounts.
• Help Desk often needed to contact systems
  administrators for routine support.
• System management and provisioning was very labor
  intensive.

8
Dataflow for account creation Pre-SSAM, SSAM v1
9
Dataflow for creation of accounts in SSAM v2
10
Password synchronization pre-SSAM
11
Password synchronization with SSAM
12
Eligibility

• Eligibility controls status of service
  (created/enabled, disabled, deleted)
• No eligibility, no services
• A person is given a network services ID (NSID)
  when they become eligible for a service managed
  by SSAM
• Processing occurs as needed throughout the day.

13
Eligibility (contd)

• History of Service Eligibility
• See by what rules a person is selected
• See what services a person has
• See when a person gained or lost eligibility
• Eligibility based on
• SSAM Groups (manually managed overrides)
• Student data (session, college, major, class,
  lab)
• Employee data (bargaining unit,
  division/department)
• Alumni data

14
Eligibility from SSAM Groups
Group
Group

• Person is put in a group
• A rule may select people from one or more groups
• A service is available to people selected by a
  given rule

Rule
Service
15
Eligibility from source system
Group
Student

• Person (student) is registered
• Rule selects registered students
• Many services available to registered students
• Person may also be put in a group to get the same
  services
• Many rules only select people from a source system

Rule
Service
Service
16
Service Relationships
Portal Role

• Define dependencies (hierarchies)
• Eligibility Flows along the connections (most of
  the time)
• Different reasons for dependency

Learning Commons
Portal Login
Active Directory
SSAM Auth
Print Account
17
Eligibility Example
Employees
Students
Employee Role
Student Role
Learning Commons
Portal Login
Active Directory
SSAM Auth
Print Account
18
Eligibility Example (cont)
HR
Student
Employee SSAM Group

• J is hired as an employee
• J is added to a SSAM group with an expiry date of
  June 30, 430PM
• SSAM creates NSID abc123
• SSAM creates service instances for
• Employee Role
• Portal Login
• Active Directory
• SSAM Auth
• Print Account
• On June 20, J is put in the HR system
• On June 30, at 430, Js group membership expires

Employees
Students
Employee Role
Student Role
Learning Commons
Portal Login
Active Directory
SSAM Auth
Print Account
19
Eligibility Example (cont)
HR
Student
Employee SSAM Group

• J registers for a class
• J already has
• Employee Role
• Portal Login
• Active Directory
• SSAM Auth
• Print Account
• SSAM creates service instances for
• Student Role
• Learning Commons

Employees
Students
Employee Role
Student Role
Learning Commons
Portal Login
Active Directory
SSAM Auth
Print Account
20
Eligibility Example (cont)
HR
Student
Employee SSAM Group

• J resigns as an employee
• SSAM turns off services
• Employee Role
• SSAM leaves the following services because J is a
  student
• Learning Commons
• Student Role
• Portal Login
• Active Directory
• SSAM Auth
• Print Account

Employees
Students
Employee Role
Student Role
Learning Commons
Portal Login
Active Directory
SSAM Auth
Print Account
21
Eligibility Example (cont)
HR
Student
Employee SSAM Group

• J finishes classes and graduates
• SSAM turns off the following services
• Student Role
• Portal Login
• Learning Commons
• Active Directory
• SSAM Auth
• Print Account

Employees
Students
Employee Role
Student Role
Learning Commons
Portal Login
Active Directory
SSAM Auth
Print Account
22
Functional Features Support Interface

• Single page to view information, set passwords,
  change quotas, etc.
• Display list of services person has and current
  eligibility status.
• Random passwords generated to give support person
  option of one to pick.
• View many services on one screen.
• Override groups can be managed outside of ITS

23
Functional Features self service

• Allow change of password
• Allow user to set email forwarding
• Display disk usage and quota for services
• Report on out of sync passwords
• Random passwords presented in case user is having
  difficulty picking one

24
Process to create a new service

• Decide on Eligibility criteria.
• Determine service dependencies.
• Modify a SSAM Daemon (if needed)
• They all have a common core with specifics to
  deal with each service type on a server.
• Define server, service, and service attributes in
  SSAM DB.
• Define and connect rules to the new service(s).

25
Design Considerations

• Security
• Transmission of data is encrypted
• Role based security, record of who performed an
  action
• Passwords are not stored in the SSAM DB
• Reliability and Robustness
• Oracle DB, redundant WiTango (application)
  servers
• Designed to be fault tolerant.
• Performance
• Handles most traffic situations. Some problems
  during first 2-3 weeks in September due to high
  demand
• Maintenance
• System is architected in a modular way to allow a
  module to be upgraded without taking all modules
  down.

26
Auditability

• Transaction History
• Can see all transactions that have been sent from
  SSAM to each service.
• Can look at results from previous transactions.
• Failed transactions (like create and enable) can
  be resent.
• Operator NSID is stored with the transaction.

27
Security

• Traffic between client web browser and web server
  is encrypted.
• Traffic between database and remote server is
  encrypted.
• Passwords are not stored by SSAM.
• Application uses role based security to determine
  what people can do.

28
(No Transcript)
29
(No Transcript)
30
Impacts on institutional processes

• Since we rely on source systems, they must be
  correct and updated in a timely manner.
• Troubleshooting why someone does not have a
  service requires knowledgeable people supporting
  SSAM.
• There may be overlapping functionality provided
  by ERPs, and you need to think about how to use
  each.
• Defining roles at an institutional level is
  beneficial.
• Clarifying the rules for access to services
  becomes more difficult without this.
• For example, when a person talks about employees
  having access, do they include student markers?

31
Some Stats as of May 12, 2005

• Number of people we can process per day 20,000.
• Average time to process eligibility 2.5 seconds
• Number of servers managed 24
• Number of services managed 818
• Max transactions handled in a single day 62,983
• Number of new NSIDs created per year 7,300
  (104,601 currently allocated)
• Number of NSIDs that have a currently active
  instance 46,950

32
Transactions over time
33
Services and Instances Managed
34
Future Directions

• Increase eligibility processing capabilities.
• Re-design and re-write parts of the UI.
• Improve service definition procedure.
• Increase self-service capabilities
• NSID and Password discovery/recovery.
• Vacation/out-of-office messages.
• Become fully buzz-word compliant.

35
Questions?