I checked this API definition and it looks good for me. Please check inline comments. However I believe this configuration won't be that simple when it comes to real implementation. As an example we will think about basic auth secured DCR, OAuth protected scope registration endpoint etc. We will need to collect a lot more parameters. So we will be able to have key-values kind of things for that.
On Thu, Apr 16, 2020 at 12:36 PM Tharindu Dharmarathna <[email protected]> wrote: > Hi All, > > Hi All, > > Please find the Admin Rest API model for Registering the Key Managers from > Admin API. > > ###################################################### > # The "Key Manager Collection" resource API > ###################################################### > /key-managers: > > #----------------------------------------------------- > # Retrieve all key managers > #----------------------------------------------------- > get: > x-scope: apim:admin_operations > summary: Get all Key managers > description: | > Get all Key managers > tags: > - Key Manager (Collection) > responses: > 200: > description: | > OK. > KeyManagers returned > schema: > $ref: '#/definitions/KeyManagerList' > > #----------------------------------------------------- > # Add a Key Manager > #----------------------------------------------------- > post: > x-scope: apim:admin_operations > summary: Add a new API Key Manager > description: | > Add a new API Key Manager > parameters: > - in: body > name: body > description: | > Key Manager object that should to be added > required: true > schema: > $ref: '#/definitions/KeyManager' > tags: > - Key Manager (Individual) > responses: > 201: > description: | > Created. > Successful response with the newly created object as entity in > the body. > schema: > $ref: '#/definitions/KeyManager' > 400: > description: | > Bad Request. > Invalid request or validation error > schema: > $ref: '#/definitions/Error' > > ###################################################### > # The "Individual KeyManager" resource APIs > ###################################################### > > /key-managers/{keyManagerId}: > > #----------------------------------------------------- > # Update a Key Manager > #----------------------------------------------------- > put: > x-scope: apim:admin_operations > summary: Update a Key Manager > description: | > Update a Key Manager by keyManager id > parameters: > - $ref: '#/parameters/keyManagerId' > - in: body > name: body > description: | > Key Manager object with updated information > required: true > schema: > $ref: '#/definitions/KeyManager' > tags: > - Key Manager (Individual) > responses: > 200: > description: | > OK. > Label updated. > schema: > $ref: '#/definitions/KeyManager' > 400: > description: | > Bad Request. > Invalid request or validation error. > schema: > $ref: '#/definitions/Error' > 404: > description: | > Not Found. > The resource to be updated does not exist. > schema: > $ref: '#/definitions/Error' > #----------------------------------------------------- > # Delete a Key Manager > #----------------------------------------------------- > delete: > x-scope: apim:admin_operations > summary: Delete a Key Manager > description: | > Delete a Key Manager by keyManager id > parameters: > - $ref: '#/parameters/keyManagerId' > - $ref: '#/parameters/If-Match' > - $ref: '#/parameters/If-Unmodified-Since' > Do we need If-Match etc here? > tags: > - Key Manager (Individual) > responses: > 200: > description: | > OK. > Key Manager successfully deleted. > 404: > description: | > Not Found. > Key Manager to be deleted does not exist. > schema: > $ref: '#/definitions/Error' > > #----------------------------------------------------- > # The KeyManager resource > #----------------------------------------------------- > KeyManager: > title: Key Manager > required: > - name > - type > properties: > id: > type: string > example: "01234567-0123-0123-0123-012345678901" > name: > type: string > example: "WSO2 IS" > type: > type: string > example: "IS" > description: > type: string > example: "This is a key manager for Developers" > introspection_endpoint: > type: string > example: "" > dynamic_client_registration_endpoint: > type: string > example: "" > token_endpoint: > type: string > example: "" > scope_management_endpoint: > type: string > example: "" > available_grant_types: > type: array > items: > type: string > example: "client_credentials" > enabled: > type: boolean > example: true > additionalProperties: > type: object > > > #----------------------------------------------------- > # The KeyManager List resource > #----------------------------------------------------- > KeyManagerList: > title: Key Manager List > properties: > count: > type: integer > description: | > Number of Key managers returned. > example: 1 > list: > type: array > items: > $ref: '#/definitions/KeyManager' > > # Key Manager Id > # Specified as part of the path expression > keyManagerId: > name: keyManagerId > in: path > description: | > Key Manager UUID > type: string > required: true > > Please let me know any feedback on this model. > > Thanks > Thanks, sanjeewa. > > On Wed, Apr 15, 2020 at 8:51 PM Tharindu Dharmarathna <[email protected]> > wrote: > >> Hi Amila, >> >> Please find my comments below. >> >> On Wed, Apr 15, 2020 at 4:03 PM Amila De Silva <[email protected]> wrote: >> >>> Hi Tharindu, >>> >>> On Tue, Apr 14, 2020 at 10:12 PM Tharindu Dharmarathna < >>> [email protected]> wrote: >>> >>>> Hi All, >>>> >>>> We are going to implement Multiple Oauth provider support to WSO2 API >>>> Management. From this feature, dev portal users can create their Oauth >>>> Application on Pre-Defined OAuth providers. >>>> >>>> 1. Tenant Admin Create Oauth Provider from the Admin portal by >>>> providing OAuth provider details. >>>> >>>> - Client Registration endpoint >>>> - Introspection Endpoint >>>> - Scope Management Endpoint >>>> - Token Endpoint >>>> - Revoke Endpoint >>>> - Endpoint Security Details >>>> - Token Validation Regex. >>>> >>>> Isn't Scope Management a custom endpoint? Is it that we are only >>> specifying it when connecting with IS? >>> >>> Some of the Oauth Provider have their own Scope Management Endpoint that >> can use. >> >> >>> 2. Application developer creates the application defining the Oauth >>>> Provider type. >>>> 3. Application developer Generates the keys from UI. >>>> >>>> - Checks for the Consumer Key Generation can be done in the >>>> Specific Oauth Provider. >>>> - Generate the Oauth App on Oauth Provider and retrieves the Oauth >>>> Application Details. >>>> >>>> 4. Application Developer Retrieves the Application details from the UI. >>>> >>>> - Check for the Oauth provider selected. >>>> - Retrieve the Oauth App details from the Respective OAuth Provider >>>> selected. >>>> >>>> 5. Generating Oauth Token >>>> >>>> - Token Generation call will directly proxy into the token endpoint >>>> of Respective Oauth Provider. >>>> >>>> Wondering if App Developers will use this at all. Isn't the more likely >>> case to get the token directly from an OAuth provider? In case we support >>> this, how about making this configurable (so Tenant Admin can decide >>> whether or not to proxy the request). Currently the Token endpoint is a >>> passthrough, but with this some changes will be needed to find the OAuth >>> provider from CK. Most probably this would include making a service call >>> from the GW. If it's likely to make unnecessary burden on the KM nodes, >>> better to provide an option to disable it. >>> >> >> We will not go to proxy the Request Through Gateway. This will show what >> will be the endpoint shows in the UI to use. >> >>> >>> >>>> 6. Validating the Token. >>>> >>>> - Generated Token from Oauth Providers contains a specific change >>>> related to the Token. >>>> >>>> So two OAuth providers can co-exist (within a single tenant space) if >>> their issued tokens can be separated by some property - Is this the case? >>> >> >> This can be the Token length, Token prefix, etc from the Token >> Management. >> >>> >>>> - Before validating the token we checking the Token was resided to >>>> which Oauth provider by checking from the Token Validation Regex given. >>>> - Token get validate from elected Oauth Provider and then retrieve >>>> the information related to the Token. >>>> >>>> 7. Delete the Application >>>> >>>> - Oauth Application will remove from Respective Oauth Provider >>>> assigned. >>>> >>>> >>>> I appreciate any thoughts and feedback on this. >>>> >>> >>> Are we only supporting this for subscriptions within the same tenant? >>> >>>> >>>> We will not be able to handle this feature in cross tenant since we >> couldn't identify the tenant of the token before going to validate it. >> >> >>> >>>> Thanks >>>> >>>> *Tharindu Dharmarathna*Technical Lead >>>> WSO2 Inc.; http://wso2.com >>>> lean.enterprise.middleware >>>> mobile: *+94779109091* >>>> >>> >>> >>> -- >>> *Amila De Silva* >>> Software Architect | Associate Director, Engineering - WSO2 Inc. >>> (m) +94 775119302 | (e) [email protected] >>> <http://wso2.com/signature> >>> >> >> >> Thanks >> >> *Tharindu Dharmarathna*Technical Lead >> WSO2 Inc.; http://wso2.com >> lean.enterprise.middleware >> >> mobile: *+94779109091* >> > > > -- > > *Tharindu Dharmarathna*Technical Lead > WSO2 Inc.; http://wso2.com > lean.enterprise.middleware > > mobile: *+94779109091* > -- *Sanjeewa Malalgoda* Software Architect | Associate Director, Engineering - WSO2 Inc. (m) +94 712933253 | (e) [email protected] | (b) Blogger <http://sanjeewamalalgoda.blogspot.com>, Medium <https://medium.com/@sanjeewa190> GET INTEGRATION AGILE <https://wso2.com/signature> Integration Agility for Digitally Driven Business
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
