1 / 13

Federating applications at NTNU EuroCAMP 17.-18.04.2007 Bjørn Ove Grøtan – Software Developer

Insights into organizing IT at NTNU, including case studies on online course planning, electronic elections, course evaluation, and phone system management. Learn how NTNU is moving towards a federated approach for applications.

ramsayj
Download Presentation

Federating applications at NTNU EuroCAMP 17.-18.04.2007 Bjørn Ove Grøtan – Software Developer

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Federating applications at NTNU EuroCAMP 17.-18.04.2007 Bjørn Ove Grøtan – Software Developer Bjorn.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 000m2 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 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.

  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 andphone-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.

More Related