View source
Visit project1 Background and motivation
Student-built applications need a reliable way to recognize IIT Bombay users without each team managing a separate identity system. I worked on ITC SSO to provide that integration boundary for campus projects. A shared service handles the institutional verification flow and returns profile information through an API, allowing applications built with different frameworks to use a common login path.
2 Application registration and authentication
An application is registered as a project with its own callback destination. It sends the user to a project-specific SSO route, after which the flow returns an access identifier to the registered callback. The application exchanges that identifier with the user-data endpoint to obtain the profile fields needed for its own session.
The documented profile includes information such as name, roll number, department, degree, and passing year. This is a redirect-and-exchange integration rather than a reason for an application to collect institutional credentials itself. Callback validation and project verification are important because the identity response must return to the intended application.
3 Implementation and administration
The service is built with Django and Django REST Framework, backed by PostgreSQL. The repository separates user profiles, registered projects, and session records, and documents MinIO for media storage. Project-management and administration views support onboarding applications and managing users, while the verification flow connects institutional identity with the service’s profile records.
Short-lived sessions limit the duration of an access identifier, and the calling application must handle expired or invalid responses. Keeping these behaviours in a central service reduces repeated implementation across campus applications, but each integrating application still controls its own authorization decisions after learning who the user is.
4 Integration boundary
Authentication establishes an identity; it does not determine every permission within a borrowing portal, competition dashboard, or club service. Those applications must still decide what that identity may do. The project’s benefit is a reusable institutional login interface, while availability of the central service and correctness of each callback integration remain operational dependencies.