In dit artikel wordt uitgelegd hoe integrators en beheerders aanmeldgegevens van Brightspace®-servicegebruikers en OAuth 2.0-clients kunnen inzetten om veilige server-naar-server-integraties te verifiëren, workflows te automatiseren en machine-naar-machine API-toegang te beheren zonder menselijke accounts.
Introductie
In het Brightspace®-ecosysteem hebben ontwikkelaars en beheerders om een eenvoudigere, veiligere manier gevraagd om integraties, automatiseringen en achtergrondservices te ondersteunen, zonder afhankelijk te zijn van menselijke accounts of langdurige tokens. Vandaag kondigen we met gepaste trots een grote stap voorwaarts aan om aan die behoefte te voldoen: Servicegebruikers, een nieuw type van niet-menselijke identiteit die speciaal voor machine-naar-machine-workloads (M2M) is ontworpen.
Servicegebruikers bieden, in combinatie met de nieuwe OAuth 2.0-clienttoegangsverlening van Brightspace® met JWT-clientbevestigingen, een modern, op standaarden gebaseerd verificatiemodel met de minste bevoegdheden voor geautomatiseerde integraties. Gezamenlijk bieden ze veilige toegang tot API's zonder gebruikersprompts, browseromleidingen of vernieuwingstokens.
Deze grote verbetering van Brightspace® plaveit de weg voor schonere, veiligere en beter te onderhouden integraties op het hele platform.
Wat zijn servicegebruikers?
Servicegebruikers zijn gespecialiseerde Brightspace®-gebruikersaccounts die zijn ontworpen voor geautomatiseerde systemen en integraties. In tegenstelling tot standaard menselijke accounts:
- hebben ze niet-interactieve API-verificatie;
- volgen ze strikte principes met de minste bevoegdheden;
- zijn ze gekoppeld aan één toepassing;
- bieden ze ondersteuning voor machtigingen met een nauw bepaald bereik met behulp van Brightspace®-rollen, en
- maken ze op voorspelbare manieren deel uit van het toegangsmodel van de organisatie.
Zie ze als machineoperators in uw Brightspace®-omgeving. Deze accounts handelen niet namens een persoon, maar namens een toepassing en beschikken alleen over de machtigingen die beheerders aan deze accounts hebben toegewezen.
Waarom we servicegebruikers maken
Instellingen en partners vragen al tijden om een eersteklas oplossing voor:
- Geplande SIS- of middleware-synchronisatietaken
- Geautomatiseerde achtergrondprocessen
- Generatie van analyses aan de serverzijde
- Vernieuwing van inhoud en catalogussynchronisatie
- Overbruggingen van systeem-naar-systeem in de infrastructuur van instellingen
Het was moeilijk om deze scenario's te ondersteunen met gedelegeerde OAuth-workflows die voor menselijke gebruikers zijn ontworpen. Servicegebruikers bieden een geschikt identiteitsmodel voor geautomatiseerde toegang dat transparant en veilig is en is afgestemd op de behoeften van niet-interactieve workloads.
Hoe passen servicegebruikers in de Brightspace®-beveiliging?
De tool Servicegebruikers is rechtstreeks ontwikkeld op basis van het Brightspace®-gebruikersrolmodel en volgt dezelfde basisprincipes voor autorisatie waar beheerders al bekend mee zijn.
Trapsgewijze toegang
Servicegebruikers kunnen op elk niveau in de Brightspace®-organisatiestructuur worden ingeschreven. Deze inschrijvingen kunnen waar van toepassing worden doorgevoerd naar organisatie-eenheden. Hierdoor krijgt een integratie toegang tot exact de cursussen of organisatie-eenheden die het nodig heeft, zonder onnodige toegang te verlenen. Beheerders kunnen deze inschrijvingen en machtigingen beheren met behulp van dezelfde modellen die ze al gebruiken voor menselijke accounts.
Duidelijk onderscheid van gebruikersinterfaces
Om het beheer schoon te houden en te voorkomen dat geautomatiseerde identiteiten worden gemixt met echte mensen:
- Servicegebruikers worden op een aparte locatie weergegeven, onder Uitbreiding beheren.
- Ze zijn uitgesloten van standaard groepslijsten, zoekopdrachten van gebruikers, exports, gegevensreeksen en niet-relevante API's.
- Configuratieopties worden gestroomlijnd zodat de focus op integratie en toegangsbeheer ligt.
Deze scheiding zorgt ervoor dat geautomatiseerde service-identiteiten eenvoudig kunnen worden beheerd en duidelijk van menselijke gebruikers kunnen worden onderscheiden.
Inleiding tot OAuth 2.0-clientreferentie met JWT-clientbevestigingen
Ter ondersteuning van servicegebruikers biedt Brightspace® nu een robuuste nieuwe verificatieworkflow op basis van OAuth 2.0.
Clienttoegangsverlening (CCG)
De clienttoegangsverlening is ontworpen voor machine-naar-machine-verificatie, waarbij een toepassing zich als zichzelf verifieert.
JWT-clientbevestigingen
In tegenstelling tot traditionele clientgeheimen is een clientbevestiging een kortdurende, ondertekende JSON-webtoken die met behulp van de privésleutel van de toepassing is gemaakt. Brightspace® valideert de token met behulp van de openbare sleutels die zijn opgeslagen in een JWKS die de beheerder tijdens het registreren van de toepassing opgeeft.
Deze benadering biedt:
- Geen gedeelde geheimen om te beheren
- Bescherming tegen herhaaldelijke aanvallen
- Kortdurende, niet-vernieuwbare tokens
- Sterke asymmetrische cryptografie
- Afstemming met OAuth 2.0 best practices (RFC 7523, RFC 7519, RFC 6749)
Het vormt een balans tussen flexibiliteit voor ontwikkelaars en sterke beveiliging voor beheerders.
Zo werken servicegebruikers met clientreferenties
Elke OAuth2.0-clientreferentietoepassing moet aan een servicegebruiker worden gekoppeld. Wanneer de toepassing om een token vraagt, gebeurt het volgende:
- Er wordt een ondertekende JWT-bevestiging verstuurd.
- Brightspace® valideert de handtekening met behulp van de geregistreerde JWKS.
- Brightspace® geeft een kortdurende toegangstoken uit.
- Elke API-aanroep die met behulp van die token wordt gemaakt, wordt uitgevoerd met de machtigingen van de gekoppelde servicegebruiker.
Een toepassing registreren: een snel overzicht
Als beheerders een clientreferentietoepassing in Brightspace® willen registreren, moeten ze het volgende doen:
- Een servicegebruiker maken
- Machtigingen met een beperkt bereik toewijzen
- Een OAuth-toepassing registreren en de JWKS-URL opgeven
- De servicegebruiker aan de toepassing koppelen
- Testen en implementeren
Deze workflow zorgt voor een lichte configuratie en behoud van sterke beveiligingsgrenzen voor instellingen.
Wanneer moet u welke OAuth-workflow gebruiken?
Scenario
|
Aanbevolen workflow
|
|---|
| Een menselijke gebruiker meldt zich aan en verleent toegang |
Autorisatiecode plus vernieuwingstokens |
| Een back-endsysteem heeft doorlopende toegang nodig, zonder aanwezige gebruikers |
Clientreferenties plus servicegebruiker |
| Geplande taken, gegevenspipelines, middleware, achtergrondsynchronisaties |
Clientreferenties plus servicegebruiker |
Opmerking: Als er geen menselijke gebruiker bij betrokken is, kan de toepassing zich als zichzelf verifiëren met behulp van een servicegebruiker.
Wat betekent dit voor ontwikkelaars en beheerders?
Met servicegebruikers en de nieuwe OAuth2.0-clienttoegangsverlening biedt Brightspace® nu het volgende:
- Een moderne verificatiemethode die is ontwikkeld op basis van industriestandaarden
- Sterke beveiliging zonder gedeelde geheimen
- Duidelijke scheiding tussen menselijke accounts en machineaccounts
- Verfijnd API-machtigingsbeheer
- Overzichtelijk beheer van de integratielevenscyclus
- Een schaalbare basis voor toekomstige uitbreidingsverbeteringen
Deze mogelijkheden versterken de algemene Brightspace®-integratie-ervaring voor instellingen en ontwikkelaars.
Wat brengt de toekomst?
We blijven de documentatie, voorbeelden en ontwikkelaarstools uitbreiden die OAuth- en Brightspace®-integraties ondersteunen. Met deze release wordt een belangrijke basis gelegd voor toekomstige verbeteringen van de manier waarop beheerders integraties configureren en beheren.
Als u integraties met Brightspace® ontwikkelt of onderhoudt, houd dat aankomende release notes en updates van onze documentatie voor ontwikkelaars in de gaten.
Aanvullende bronnen