1. SLT Refactoring and JWT Authentication: Two Upgrade Proposals M Chavan, ESO

2. Shift Log Tool Refactoring

3. Some History Shift Log Tool was the first ObOps deliverable, 3Q2006
Several developers over the years
Scope increased dramatically
The context (on- and offline SW) changed as well

4. Very First Version
Requirement: keep a log of Science activities

5. Major Change Requirement: react to system events
SchedBlockStarted, etc.

6. Tight Coupling with Online SW
SLT effectively became Online SW
Business logic was in the stand-alone tool and in the ACS component
New sci-ops requirements required backporting to Online code base
Increasingly difficult towards end of cycle

7. Online and Offline Desktop SLT shares code with Web SLT
Desktop was online, Web was offline

8. 2015.8 - Decoupling from ACS No business logic in online component
Remove offline dependencies from ACS

9. All is Not Well

10. All is Not Well / 2 Modules are duplicated in every STE
Multiply failure sources
We (ObOps) still have an online module
Debugging is very difficult
Especially from Europe

11. New Architecture A new ACS component writes to a staging DB
SLTs only interacts with their DB

12. New ACS Component Receives and writes CORBA Events
Makes CORBA calls and writes results
Limited scope
Low maintenance

13. Division of Responsibilities
New ACS component to be written, maintained by SW Ops team
ACS experts
Close contact with online environment
Offline components to be refactored by ObsIF

14. Plan for Cycle 5 Agree on the path forward Spec the new ACS component
Implement and deploy it
In parallel to existing implementation?
Re-engineer offline modules

15. JWT Authentication

16. Web-based Application Security
Currently using Central Authentication Service (CAS)
Was tool of choice when we started
Popular in academia (only)
Provides Single Sign-On
Good for server-side applications

17. Server-side Applications

18. Single Page Applications

19. Single Page Applications
Single Page Applications load only once
Communicate async with one or more REST servers
Response is used to modify the Web page locally

20. Single Page Applications
Front-end and back-end are clearly separate
Front-end: visualization, interaction
Back-end: data management, business logic
Back-ends may serve non-GUI clients as well
Back-ends should be secured

21. Why not CAS for SPAs? No machine-to-machine authentication
Dashboard receives “events” from script
AQUA requires services from AQUA/Pipeline Agent
SnooPI requires services from AQUA, Project Tracker
Requires a complex 3-way “dance”
Front-end (JavaScript), REST back-end, CAS
Done for SnooPI, no general solution

22. Securing Servers with JWTs
JSON Web Tokens are open standard
Transmitting information securely
Encoded, digitally signed, optionally encrypted
Self-contained: contain all required information
User info (authentication/authorization)

23. JWT Pros Apply to SPAs and server-side Web apps
Stateless (JWT itself is the state)
Self-contained
Only one authentication/authorization DB query
Survive auth and app server restarts
Support Single Sign-On and -Off
Used by VLT, JIRA, and many more

24. JWT Cons No “best practices” (it’s a protocol) No magic bullet
Security always implies tradeoffs

25. Backwards compatibility
ALMA, ESO, NRAO all invested in CAS
Any alternatives must provide a path forward and integrate with CAS
Browser-based Single Sign-On must be preserved: users must be able to
Sign-On with CAS and use JWT-secured resources
Sign-On with JWT and use CAS-secured resources

26. Status General concepts fully clarified
Expert panel gave positive feedback
Prototype written as proof-of-concept
No existing resources available
Encouraging results
CAS/JWT integration seems viable
Protorype soon to be reviewed by expert panel

27. Plan Implement CAS/JWT integrated solution
Migrate existing apps to JWT auth
Dashboard back-end
SnooPI
AQUA/Pipeline Agent
User Portal?
Investigate whether porting AQUA, Protrack, …

28. Conclusions
TO-DO

29. The Atacama Large Millimeter/submillimeter Array (ALMA), an international astronomy facility, is a partnership of Europe, North America and East Asia in cooperation with the Republic of Chile. ALMA is funded in Europe by the European Organization for Astronomical Research in the Southern Hemisphere (ESO), in North America by the U.S. National Science Foundation (NSF) in cooperation with the National Research Council of Canada (NRC) and the National Science Council of Taiwan (NSC) and in East Asia by the National Institutes of Natural Sciences (NINS) of Japan in cooperation with the Academia Sinica (AS) in Taiwan. ALMA construction and operations are led on behalf of Europe by ESO, on behalf of North America by the National Radio Astronomy Observatory (NRAO), which is managed by Associated Universities, Inc. (AUI) and on behalf of East Asia by the National Astronomical Observatory of Japan (NAOJ). The Joint ALMA Observatory (JAO) provides the unified leadership and management of the construction, commissioning and operation of ALMA.