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'
      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

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*
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to