Developer Portal
There is customer demand for a developer portal that allows developers to self-service their clients in the Gluu OP. This would enable developers to perform basic CRUD operations for their clients. They could also request additional scopes. For example, by default, dynamically registered clients only get the
openidanduma_protectionscope. The developer may want to request theprofilescope as well. The only process for this currently is to manually request the OP admin to grant the client additional scopes. A streamlined and repeatable process for handling this type of developer request to the OP admin would be very useful.
The design is really important, with very thorough consideration of approvals and auditing
https://github.com/GluuFederation/casa-ee-plugins
- Developer - An authenticated person who can register clients and request additional scopes.
- Administrator - A person who can manage scope requests on behalf of an organization.
The scope and claim which convey the Casa Role should be configurable.
The Gluu Server admin would have to make sure that this scope existed, the claim was associated with it, and that Casa was authorized to request this scope.
The database layer should be abstracted, with different implementations possible.
The first persistence implementation should be LDAP.
- We should update gluuPerson objectclass to add the attribute "oxAssociatedClient", which should reference the DN of the client. Casa should then lookup the respective client.
Developer portal should have convenient way to define message channel to notify about approval_request/approval_decision. The messaging mechanism should allow convenient way to configure
notification channels (i.e default would be email but organization can add custom channel to trigger internal notification system).
Proposition: ?
| Name | Actor | Use Case |
|---|---|---|
| Create OP client | Developer | 1. Developer logs into Gluu Casa 2. Developer clicks Developer portal tab 2. Developer fills client form 3. Developer saves client 4. Client is created in OP |
| View OP client list | Developer | 1. Developer logs into Gluu Casa 2. Developer clicks Developer portal tab 2. By default Developer sees list of owned clients |
| View OP client details | Developer | 1. Developer logs into Gluu Casa 2. Developer clicks Developer portal tab 2. Developer clicks on client name 3. Developer can see details about client (Should it contain the same data as OP Client view from CE?) |
| Edit OP client | Developer | 1. Developer logs into Gluu Casa 2. Developer clicks Developer portal tab 2. Developer clicks on client edit icon 3. Developer can change the client data (should it be the same as in CE?) 3. Data is changed in CE |
| Delete OP client | Developer | 1. Developer logs into Gluu Casa 2. Developer clicks Developer portal tab 2. Developer clicks on client edit icon 3. Client is deleted in CE |
| Scope requesting | Developer | 1. Developer logs into Gluu Casa 2. Developer clicks Developer portal tab 2. Developer clicks on client edit icon 3. Developer clicks on scope request button 4. Developer selects scopes from list and accepts 5. Request appears in pending request list, Administrator is notified (all of Administrators?) 5. After approval client gets the scopes |
| Scope manual approval | Administrator | 1. Administrator logs into Gluu Casa 2. Administrator clicks Developer portal tab 2. Administrator clicks on pending requests 3. Administrator sees requests list with client details, Developer details and requested scopes and buttons to accept/reject. 4. In case of rejection Administrator has to fill reason field which is forwarded to Developer 5.Request disappears form list, Developer is notified (email) |
| Admin scope accept script | Administrator | 1. Administrator logs into Gluu Casa 2. Administrator clicks Developer portal tab 2. Administrator clicks on accepting scripts list 3. Administrator can enter custom script (language?), per scope (group of scopes) which returns True/False 4. Script is executed each time assigned scope is requested. |
| Client field | Access | Is in Developer portal |
|---|---|---|
| Inum | READ | YES |
| Client Name: | WRITE | YES |
| Client Description: | WRITE | YES |
| Client Secret: | WRITE (plaintext?) | YES |
| Application Type: | WRITE | YES |
| Pre-Authorization: | WRITE | YES |
| Persist Client Authorizations: | WRITE | YES |
| Logo URI: | WRITE | YES |
| Client URI: | WRITE | YES |
| Policy URI: | WRITE | YES |
| Terms of Service URI: | WRITE | YES |
| JWKS URI: | ? | ? |
| JWKS: | ? | ? |
| Sector Identifier URI: | ? | ? |
| Subject Type: | ? | ? |
| JWS alg Algorithm for signing the ID Token: | ? | ? |
| JWE alg Algorithm for encrypting the ID Token: | ? | ? |
| JWE enc Algorithm for encrypting the ID Token: | ? | ? |
| JWS alg Algorithm for signing the UserInfo Responses: | ? | ? |
| JWE alg Algorithm for encrypting the UserInfo Responses: | ? | ? |
| JWE enc Algorithm for encrypting the UserInfo Responses: | ? | ? |
| JWS alg Algorithm for signing Request Objects: | ? | ? |
| JWE alg Algorithm for encrypting Request Objects: | ? | ? |
| JWE enc Algorithm for encrypting Request Objects: | ? | ? |
| Authentication method for the Token Endpoint: | ? | ? |
| JWS alg Algorithm for Authentication method to Token Endpoint: | WRITE | YES |
| Default Maximum Authentication Age: | ? | ? |
| Require Auth Time: | ? | ? |
| Redirect Login URIs: | WRITE | YES |
| Post Logout Redirect URIs: | WRITE | YES |
| Claim Redirect URIs: | WRITE | YES |
| Scopes: | WRITE(request) | YES |
| Individually Requested Claims: | WRITE | YES |
| Response Types: | WRITE | YES |
| Grant Types: | WRITE | YES |
| Contacts: | WRITE | YES |
| Request URIs: | WRITE | YES |
| Authorized JavaScript Origins: | ? | ? |
| Front Channel Logout URI: | ? | ? |
| Logout Session Required: | ? | ? |
| Include Claims In Id Token: | ? | ? |
| Refresh Token Lifetime: | ? | ? |
| oxd Id: | ? | ? |
| Disabled: | WRITE | YES |
| Client's Registration Expires: | WRITE | YES |