1

Federating applications at NTNU

EuroCAMP 17.-18.04.2007Bjørn Ove Grøtan – Software DeveloperBjorn.grotan@ntnu.no

Federating applications at NTNU

2

NTNU in numbers• 53 departments in 7 faculties• 2 main campuses• NTNU Library• Museum of Natural History and Archaeology

• 58 000 student applications a year – of which 9000 have NTNU as their first choice

• 20 000 registered students, 7000 admitted/year• 3000 degrees awarded a year• 220 doctoral degrees awarded a year

• 4320 employees• 2600 empl. in education and research; 555 professors• Budget: NOK 3.6 billion• 555 000 m2 owned and rented premises

3

The next 20-30 minutes

• Organizing IT at NTNU• Example cases

4

Organizing IT at NTNU

• One central IT-dept. (aprox 100 persons) – Customer services

– System/Network administration

– Development

• Decentralized IT per faculty and even at some Institutes. Ranges from 2-3 to 20+

5

Case #1 Online Course planning

• Each institute/teacher plan their courses outside theSAS (School/Student Administrative System)

• Datamodel derived from the central SAS (FS)• Shared database. Security and integrity handled by

Oracles VPD-technology (Virtual Private Database).• Evolutionary developed using prototyping.• Challenges met when SAS is used quite differently

between the institutions.– Identifying and generalizing biggest challenges, but this has also

benifitted the overall application architecture.

6

Case #2 Electronic Elections

• Authentication pr Institution still done using plain old LDAP-authentication– A list of LDAP-servers can be configured for use for each

institution.

• Federated database in terms of DB-schema perinstitution. Some DBA-gruntwork needed for each new institution

• Applicationspecific challenges regarding rules of elections

• SLA, routines, monitoring, professionalising the Service-Provider role.

• Leadingtexts is still a challenge

7

Case #3 Course evaluation

• Web-based application where teachers can invite students internally or anyone to evaluate their courses.

• Wizard-based forms aimed to help the teachers.• Sprung out from a demand set by the National

Quality Reform given by the Norwegian Government.

8

Case #4 Phone-system

• 4 Ericsson MD phonecentral, including IP-PBX• Running PBX for NTNU, HiST, Sintef and 40+ companies• Shared database (Pervasive SQL). Integrated with Kjernen and

the regional StOlav’s hospital for our staff at the medical Faculty.

• Shared administrative application and web-application• Web-application is CGI running on MS IIS• Authentication tested using integrated with AD and

phone-number + pin• Work in progress to also support the Feide-model

9

External Service Providers

• Frida (Feide-enabled)• ExLibris Metalib. Schib-connector or perl-scripts?• IT’s Learning LMS. Uses homegrown SSO but is

enabled for Feide.• Bluegarden (Economy, payroll etc) supports SAML!!

• How to enable deep-linking between applications while supporting multiple organizations and possibly multiple AuthN-methods.

10

Information federation

• Moving towards a Service Oriented Architecture• Started with database federation in 2003 (Kjernen)• Services enabled using plsql to hide the datamodel

from the applications. • Services exposed as Java APIs as well as

WebServices (SOAP over https)• Advise to perform a top-to-bottom approach

– Which services do we need vs which information do we have

– Categorize your information: Organization, Study-elements, Student, Employee etc.

11

.. continued

• Moving towards a portal-based world. • Further application federation using portlets.• Challenge to expand existing applications for inter-institutional

use.

• Developing federated applications– Identify needs– Develop objectives– Develop federation conceptual model– Develop scenarios– Perform conseptual analysis– Develop federation requirements

12

AuthZ, AuthN and Provisioning

• AuthZ is mainly a application-spesific issue• Small examples where

eduPersonAffiliation=employee has been used for lightweight AuthZ

• DB-federation where needed (integrating SAS, HR, Access Mgmt, Phone Mgmt etc). Username, email and other user-attributes fetched using Feide

• Still too many AuthN-systems. Feide vs homegrown internal SSO vs LDAP/Kerberos/MS-AD.Long term goal to achieve one SSO-system rather than 2 or 3.

13

Homegrown AuthN/SSO

• 142 defined targets (possible serviceproviders)• Aprox. 10-20% of the targets in daily use.• 40-50 points of contact for the SSO-targets.

Information at the right level is a challenge.• Some lightweight AuthZ is possible. Main orgUnit and

affiliation for each user.