130 likes | 247 Views
Federating applications at NTNU EuroCAMP 17.-18.04.2007 Bjørn Ove Grøtan – Software Developer Bjorn.grotan@ntnu.no. Federating applications at NTNU. NTNU in numbers. 53 departments in 7 faculties 2 main campuses NTNU Library Museum of Natural History and Archaeology
E N D
Federating applications at NTNU EuroCAMP 17.-18.04.2007 Bjørn Ove Grøtan – Software Developer Bjorn.grotan@ntnu.no Federating applications at NTNU
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 000m2 owned and rented premises
The next 20-30 minutes • Organizing IT at NTNU • Example cases
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+
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 byOracles VPD-technology (Virtual Private Database). • Evolutionary developed using prototyping. • Challenges met when SAS is used quite differentlybetween the institutions. • Identifying and generalizing biggest challenges, but this has also benifitted the overall application architecture.
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
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.
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 andphone-number + pin • Work in progress to also support the Feide-model
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.
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.
.. 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
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.
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.