Voeg optie voor oidcng clients toe

[phavekes]

This issue is imported from pivotal - Originaly created at Jun 14, 2019 by Bart Geesink

We hebben een nieuwe OIDC implementatie, waarvoor we ook ondersteuning willen in het SP dashboard.

Er is een nieuw entity type in Manage toegevoegd (hiervoor heb je manage > 4.0 voor nodig, op het tijdstip van schrijven is dat 4.0.4)

We willen de oidcng ondersteuning graag per service aan- of uit kunnen zetten zodat we kunnen testen met een select groepje. Wat ook mag is dat wanneer het niet specifiek is ingesteld voor een service, de optie wel komt in de "new entity modal" maar dat deze is uitgegrijsd. Zo kunnen we een aantal SPs laten testen met de nieuwe oidc instance. Verder willen we graag per omgeving (test of prod) de nieuwe oidc kunnen gebruiken. Zo kunnen SPs op de testomgeving alvast beginnen zonder dat ze naar productie kunnen.

In de bijlage staat een json export van een nieuwe oidc entity.

Hieronder even een puntsgewijze opsomming van wat er moet gebeuren, wellicht dat we dit verder moeten uitwerken in aparte stories

• Vinkje om in te stellen per service: "Allow oidcng entities"
• Configuratie optie om per manage omgeving (manage_test en manage_prod) oidcng entities te kunnen provisionen
• Als allow oidcng entity aanstaat bij de service aanstaat: Voeg optie toe aan de new entity (test) modal: "OpenID Connect (NEW)" (tekst moet aanpasbaar zijn).
• ALs de prod oidcng optie aanstaat moet bovenstaande ook kunnen bij een new entity voor productie
• Schakel de knop: Copy to production uit als een oidcng niet aanstaat voor productie

Metadata velden (dit is de minimale set, er komen nog meer, maar dat zijn losse stories)

"NameIDFormat" : Zelfde als bij SAML, keuze tussen transient en persistent "accessTokenValidity" : Default op 3600, maximaal 86400 "name:en" : "Zelfde als bij SAML" "name:nl" : "Zelfde als bij SAML" "description:en" : "Zelfde als bij SAML" "description:nl" : "Zelfde als bij SAML" "grants": alleen authorization_code isPublicClient" : true, "redirectUrls" : idem als in oude oidc secret" : "een secret"

[phavekes]

(Teun Fransen - Jun 17, 2019)

[phavekes]

Vragen:

"accessTokenValidity" : Default op 3600, maximaal 86400 Wordt dit een nieuw veld dat je alleen voor de Next Gen entities mag invullen? "grants": alleen authorization_code Grants slaan we nu ook al op toch? isPublicClient" : true, Wordt dit een nieuw veld dat je alleen voor de Next Gen entities mag invullen? Of is dit altijd true? secret" : "een secret" Het secret blijft hetzelfde wat encoding methode betreft?

Hoe kunnen we onderscheid maken tussen oidc en oidcng entities bij het interacteren met Manage? (Michiel Kodde - Jun 17, 2019)

[phavekes]

Voor alles wat we hier doen geldt dat een nieuw type entity in Manage is gemaakt. Ik had beloofd om een json van dit type op te nemen in de bijlage, en ik zie dat ik dat verzuimd had. Bij deze dus.

Dus die genoemde metadatavelden moeten opnieuw worden geimplementeerd. De secret methode ga ik even achteraan. (Bart Geesink - Jun 18, 2019)

[phavekes]

Gegeven je voorbeeld.

Wat doe ik met de allowedResourceServers? Met welke waarden vul ik deze?

"allowedResourceServers": [{
        "name": "client_id_resourceserver"
    }, {
        "name": "naam_en"
    }]

Het naam_en spreekt voor zich, is het client_id gelijk aan het entity/client id?

Contacts & Attributen In het voorbeeld zie ik geen arp en contactpersonen. Is dit iets wat ik uitzet in het oidcng formulier in SP-dashboard?

Grants Is het goed als ik hier een hidden form field van maak? En dat deze dus altijd met authorization_code gevuld is?

Public client Dit moet een checkbox worden denk ik heh?

Discovery URL In je manage export zie ik een discoveryurl mag ik deze bij pushen naar manage ook invullen, of is dat iets dat Manage zelf aanvult? (Michiel Kodde - Jun 26, 2019)

[phavekes]

allowedResourceservers: Graag leeg laten: Dit gaan we in een later ticket vullen. Dit is een soort ACL voor resource servers Contacts & attributen: Die moeten gewoon gevuld worden. Grants: Die ga ik ook in een verdere story nog even verder uitwerken. Voor nu voldoet een hidden form field eker Public client: Extra checkbox toevoegen met de titel: Public client that uses PKCE: Tick this box when you have a public client like an java script or mobile app and you don\'t want to use a secret in the code flow. Discovery URL: Mag voor nu leeg gelaten worden. Gaan we op een later tijdstip mee aan de slag. Wellicht kan deze ook gewoon helemaal weg.

(Bart Geesink - Jun 27, 2019)

[phavekes]

Nog twee aanvullingen:

1) Er is een nieuwe playground, dus voor test en prod graag twee nieuwe configuratie opties creeeren zodat we deze als Playground redirect URL kunnen meegeven 2) De clientID willlen we zonder : en \'@\' transformatie doen. Voorlopig gaan we de URL gebruiken zonder het protocol gedeelte: Men geeft dan een URL op, en wij halen het protocol gedeelte (http::// of https://) eraf. Is dat te doen? (Bart Geesink - Jun 28, 2019)