On Tue, Aug 20, 2019 at 4:35 PM Bhathiya Jayasekara <bhath...@wso2.com>
wrote:

>
>
> On Tue, Aug 20, 2019 at 4:27 PM Harsha Kumara <hars...@wso2.com> wrote:
>
>>
>>
>> On Tue, Aug 20, 2019 at 3:35 PM Bhathiya Jayasekara <bhath...@wso2.com>
>> wrote:
>>
>>>
>>>
>>> On Tue, Aug 20, 2019 at 3:27 PM Malintha Amarasinghe <malint...@wso2.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, 19 Aug 2019, 20:01 Vithursa Mahendrarajah, <vithu...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I have started the implementation. When giving roles with userstore
>>>>> domain name separated with "/", *HTTP/1.1 400 Bad Request* error
>>>>> response is returned, as encoded slashes is not allowed by default in
>>>>> tomcat. As suggested in [1], when adding the system property
>>>>> *org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true*, this
>>>>> issue is sorted.
>>>>>
>>>>> After this changes, the request to validate roles in secondary
>>>>> user-store fails with the error response - *HTTP/1.1 401 Unauthorized*.
>>>>> It is due to failed scope validation in [2]. This behavior is observed
>>>>> because the path parameter is decoded during authentication phase. After
>>>>> analysis found that, currently we are using
>>>>> *org.apache.cxf.message.Message.PATH_INFO* parameter ([3]) from
>>>>> request which has the decoded value. In order to resolve this issue, we 
>>>>> can
>>>>> use *org.apache.cxf.request.uri* parameter in message which is
>>>>> encoded.
>>>>>
>>>>> For instance, for the request URL -
>>>>> https://localhost:9443/api/am/publisher/v1.0/roles/
>>>>> *Internal%2Fcreator*,
>>>>> org.apache.cxf.message.Message.PATH_INFO:
>>>>> "/api/am/publisher/v1.0/roles/Internal/creator"
>>>>> org.apache.cxf.request.uri:
>>>>> "/api/am/publisher/v1.0/roles/Internal%2Fcreator"
>>>>>
>>>>> If we are proceeding with the following format of request, we need to
>>>>> add the system property and make relevant changes in scope validation 
>>>>> logic
>>>>> (WebAppAuthenticatorImpl.java):
>>>>> https://localhost:9443/api/am/publisher/v1.0/roles/
>>>>> *{user-store-name}/{role-name}*
>>>>>
>>>>> However, found [5], [6] related to the security concerns in setting
>>>>> org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH as true by 
>>>>> default.
>>>>>
>>>>> The * org.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH*
>>>>>> and *org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH* system
>>>>>> properties allow non-standard parsing of the request URI. Using these
>>>>>> options when behind a reverse proxy may enable an attacker to bypass any
>>>>>> security constraints enforced by the proxy.
>>>>>>
>>>>>
>>>> This is a good finding. Given this issue, I don't think it is a good
>>>> idea to proceed with the encoded slash in the path.
>>>>
>>>>>
>>>>> Alternatively, we can pass user-store in following ways:
>>>>>
>>>>>    1. /roles/{rolename}?userstore={userstore}
>>>>>    2. /userstore/{userstore}/roles/{roleName}
>>>>>    3. /roles/{rolename}/userstore/{userstore}
>>>>>    4. Or, need to have a configurable character to differentiate
>>>>>    user-store and role name. For instance, roles/{userstore}*-*
>>>>>    {roleName}
>>>>>
>>>>> Which way we can implement? Appreciate your suggestions regarding this.
>>>>>
>>>>
>>>> How do we treat Internal roles? Can we treat "Internal" as a user
>>>> store?
>>>>
>>>> Eg: check if "Internal/subscriber" is available:
>>>>
>>>> HEAD /roles/subscriber?userStore=Internal
>>>>
>>>> Is this a valid way of representing it?
>>>>
>>>
>>> If we're not allowed to create secondary userstores with the name
>>> "Internal", this should be ok.
>>>
>> For internal roles should be pass this at all?
>>
>
> That should be the behavior for the users in the primary user store right?
>
I meant userstore name shouldn't be mandatory parameter for checking
internal role existence.  If not user store means we can treat it as a
internal role?

>
> Thanks,
> Bhathiya
>
>
>>
>>> Thanks,
>>> Bhathiya
>>>
>>>
>>>>
>>>>
>>>>>
>>>>> [1] https://issues.apache.org/jira/browse/CXF-4207
>>>>> [2]
>>>>> https://github.com/wso2/carbon-apimgt/blob/master/components/apimgt/org.wso2.carbon.apimgt.rest.api.util/src/main/java/org/wso2/carbon/apimgt/rest/api/util/impl/WebAppAuthenticatorImpl.java#L138
>>>>> [3]
>>>>> https://github.com/wso2/carbon-apimgt/blob/master/components/apimgt/org.wso2.carbon.apimgt.rest.api.util/src/main/java/org/wso2/carbon/apimgt/rest/api/util/impl/WebAppAuthenticatorImpl.java#L113
>>>>> [4]
>>>>> https://serverfault.com/questions/914847/stop-apache-from-decoding-characters-from-uri-for-path-info
>>>>> [5] https://backstage.forgerock.com/knowledge/kb/article/a59558448
>>>>> [6]
>>>>> http://tomcat.apache.org/tomcat-9.0-doc/security-howto.html#System_Properties
>>>>> <http://tomcat.apache.org/tomcat-9.0-doc/security-howto.html>
>>>>>
>>>>> <http://tomcat.apache.org/tomcat-9.0-doc/security-howto.html>
>>>>> Thanks,
>>>>> Vithursa
>>>>>
>>>>> On Fri, Aug 16, 2019 at 11:07 AM Vithursa Mahendrarajah <
>>>>> vithu...@wso2.com> wrote:
>>>>>
>>>>>> Ack, will do that.
>>>>>>
>>>>>> On Fri, Aug 16, 2019 at 12:16 AM Harsha Kumara <hars...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> @Vithursa Mahendrarajah <vithu...@wso2.com> Once you implement,
>>>>>>> let's add several test cases with special characters, secondary user 
>>>>>>> store
>>>>>>> roles and etc.
>>>>>>>
>>>>>>> On Thu, Aug 15, 2019 at 4:16 PM Vithursa Mahendrarajah <
>>>>>>> vithu...@wso2.com> wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> Thanks for the suggestions. As per the suggestions, we have decided
>>>>>>>> to go with HEAD request option. As mentioned earlier in this thread,
>>>>>>>> following are the scenarios where role validation is required:
>>>>>>>>
>>>>>>>>    1. API Design phase -
>>>>>>>>    - Publisher access control - check whether the role exists and
>>>>>>>>       the logged-in user has the role
>>>>>>>>    - Store visibility - check whether the role exists or not
>>>>>>>>    2. API Manage phase - when adding new scope - check whether the
>>>>>>>>    role exists or not
>>>>>>>>
>>>>>>>> We have decided to add the OAuth2 scope as apim:api_create as these
>>>>>>>> functionalities are used by API creator.
>>>>>>>>
>>>>>>>> As per the offline discussion had with @Malintha Amarasinghe
>>>>>>>> <malint...@wso2.com>  and @Kasun Thennakoon <kasu...@wso2.com>,
>>>>>>>> when checking whether the logged-in user has particular role, claims 
>>>>>>>> in ID
>>>>>>>> token stored in browser local storage could be used. By considering the
>>>>>>>> possibility of manipulating the ID token in local storage, complexity 
>>>>>>>> in
>>>>>>>> handling when using secondary userstore and the security concerns in
>>>>>>>> exposing roles assigned to particular user, we have decided to
>>>>>>>> introduce another REST API to check whether the logged-in user has the
>>>>>>>> given role as this would be more cleaner.
>>>>>>>>
>>>>>>>> Please find the REST API definition as follows:
>>>>>>>>
>>>>>>>> ######################################################
>>>>>>>> # The Role Name Existence
>>>>>>>> ######################################################
>>>>>>>>   /roles/{roleName}:
>>>>>>>> #-----------------------------------------------------
>>>>>>>> # The role name existence check resource
>>>>>>>> #-----------------------------------------------------
>>>>>>>>     head:
>>>>>>>>       security:
>>>>>>>>         - OAuth2Security:
>>>>>>>>             - apim:api_create
>>>>>>>>       summary:
>>>>>>>>         Check given role name already exists
>>>>>>>>       description:
>>>>>>>>         Using this operation, to check whether given role already 
>>>>>>>> exists
>>>>>>>>       parameters:
>>>>>>>>         - $ref : '#/parameters/roleName'
>>>>>>>>       responses:
>>>>>>>>         200:
>>>>>>>>           description:
>>>>>>>>             OK.
>>>>>>>>             Requested role name is returned.
>>>>>>>>         404:
>>>>>>>>           description:
>>>>>>>>             Not Found.
>>>>>>>>             Requested role name does not exist.
>>>>>>>>
>>>>>>>> ######################################################
>>>>>>>> # The Role Name Existence for the logged-in user
>>>>>>>> ######################################################
>>>>>>>>   /me/roles/{roleName}:
>>>>>>>> #-----------------------------------------------------
>>>>>>>> # Validate role against a user
>>>>>>>> #-----------------------------------------------------
>>>>>>>>     head:
>>>>>>>>       security:
>>>>>>>>         - OAuth2Security:
>>>>>>>>             - apim:api_create
>>>>>>>>       summary:
>>>>>>>>         Validate whether the logged-in user has the given role
>>>>>>>>       description:
>>>>>>>>         Using this operation, logged-in user can check whether he has 
>>>>>>>> given role.
>>>>>>>>       parameters:
>>>>>>>>         - $ref : '#/parameters/roleName'
>>>>>>>>       responses:
>>>>>>>>         200:
>>>>>>>>           description:
>>>>>>>>             OK.
>>>>>>>>             Logged-in user has the role.
>>>>>>>>         404:
>>>>>>>>           description:
>>>>>>>>             Not Found.
>>>>>>>>             Logged-in user does not have the role.
>>>>>>>>
>>>>>>>> Appreciate any feedback on this.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Vithursa
>>>>>>>>
>>>>>>>> On Thu, Aug 15, 2019 at 11:35 AM Naduni Pamudika <nad...@wso2.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> +Vithursa Mahendrarajah <vithu...@wso2.com>
>>>>>>>>>
>>>>>>>>> On Mon, Aug 12, 2019 at 5:26 PM Sanjeewa Malalgoda <
>>>>>>>>> sanje...@wso2.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Aug 8, 2019 at 9:08 PM Malintha Amarasinghe <
>>>>>>>>>> malint...@wso2.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> When we return a 404, it implies that the URL (or the resource)
>>>>>>>>>>> does not exist. Here the URL/resource is */validate-role *(a
>>>>>>>>>>> controller resource) which always exists so it is wrong to return a 
>>>>>>>>>>> 404 at
>>>>>>>>>>> any case.
>>>>>>>>>>>
>>>>>>>>>> Yes agree with this and controller resource(as query params
>>>>>>>>>> optional controller resource will be resource) is not ideal for this.
>>>>>>>>>> Using head would be good option. Like nirmal mentioned any
>>>>>>>>>> additional parameters related to filter criteria can be passed as 
>>>>>>>>>> query
>>>>>>>>>> parameters.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> sanjeewa/
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks!
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Aug 8, 2019 at 7:12 PM Menaka Jayawardena <
>>>>>>>>>>> men...@wso2.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Naduni,
>>>>>>>>>>>>
>>>>>>>>>>>> Wh the GET request always returns 200?
>>>>>>>>>>>> Can't we set the status code 404 if the role is not found? So
>>>>>>>>>>>> we can check the response status from the UI. We do not want to 
>>>>>>>>>>>> read the
>>>>>>>>>>>> body then.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Aug 8, 2019 at 6:05 PM Naduni Pamudika <nad...@wso2.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks all for the suggestions. With the GET method @Bhathiya
>>>>>>>>>>>>> Jayasekara <bhath...@wso2.com> suggested, we have the
>>>>>>>>>>>>> following 2 options now.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. *HEAD /roles/{roleName}*
>>>>>>>>>>>>> 2. *GET /validate-role?role=rolename*
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> If we go with the option 1, it will simplify the work in the
>>>>>>>>>>>>> UI side while doing the role validations by using the Rest API 
>>>>>>>>>>>>> since we can
>>>>>>>>>>>>> do the validation by looking at the status code (If the role 
>>>>>>>>>>>>> exists it is a
>>>>>>>>>>>>> 200 and if not it is a 404). If we go with the option 2, it will 
>>>>>>>>>>>>> always
>>>>>>>>>>>>> return a 200 status code and we need to check the response body 
>>>>>>>>>>>>> to validate
>>>>>>>>>>>>> a particular role name (We can send *isRoleExist=true* and
>>>>>>>>>>>>> *isRoleExist=false* in the response body depending on the
>>>>>>>>>>>>> existence of a role name).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Since most of us are +1 with the option 2, shall we move
>>>>>>>>>>>>> forward with the GET method?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Naduni
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Aug 7, 2019 at 7:27 PM Bhathiya Jayasekara <
>>>>>>>>>>>>> bhath...@wso2.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Aug 7, 2019 at 6:24 PM Malintha Amarasinghe <
>>>>>>>>>>>>>> malint...@wso2.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, Aug 7, 2019 at 3:39 PM Harsha Kumara <
>>>>>>>>>>>>>>> hars...@wso2.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Wed, Aug 7, 2019 at 3:37 PM Malintha Amarasinghe <
>>>>>>>>>>>>>>>> malint...@wso2.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Wed, Aug 7, 2019 at 3:35 PM Harsha Kumara <
>>>>>>>>>>>>>>>>> hars...@wso2.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Let's say if someone wants to check existence of role foo
>>>>>>>>>>>>>>>>>> in user store TEST. He will do a call /roke/TEST/foo which 
>>>>>>>>>>>>>>>>>> isn't valid
>>>>>>>>>>>>>>>>>> request right?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> @Harsha Kumara <hars...@wso2.com>  we need to URL encode
>>>>>>>>>>>>>>>>> the role name. The request will become /roles/TEST%2Ffoo
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes that's true. Again some customers might have different
>>>>>>>>>>>>>>>> letters in their role names. Might note be a good idea to 
>>>>>>>>>>>>>>>> include as a path
>>>>>>>>>>>>>>>> parameter.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Even if we add as a query param, that will go as part of the
>>>>>>>>>>>>>>> URL which might lead to similar issues? We may need to test 
>>>>>>>>>>>>>>> this for query
>>>>>>>>>>>>>>> parameters as well.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I preferred the HEAD method due to the simpleness ( only
>>>>>>>>>>>>>>> need to respond with 204 or 404 without any payload based on the
>>>>>>>>>>>>>>> availability of the role) and RESTfulness (consider a role as a 
>>>>>>>>>>>>>>> resource
>>>>>>>>>>>>>>> and do a fetch on it in the usual way). HEAD is the usual way 
>>>>>>>>>>>>>>> for checking
>>>>>>>>>>>>>>> the existence of a resource. However, we do not have the need 
>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>> implementing a GET here for now.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is actually my worry is. I don't think we'll ever have
>>>>>>>>>>>>>> to give a /roles/{role} in the publisher APIs. So having a HEAD 
>>>>>>>>>>>>>> without a
>>>>>>>>>>>>>> GET feels strange to me. Maybe it's just me.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Bhathiya
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Wed, Aug 7, 2019 at 3:33 PM Mushthaq Rumy <
>>>>>>>>>>>>>>>>>> musht...@wso2.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Adding [Architecture]
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Wed, Aug 7, 2019 at 3:30 PM Mushthaq Rumy <
>>>>>>>>>>>>>>>>>>> musht...@wso2.com> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Since we will be UserStoreManager, this should cover
>>>>>>>>>>>>>>>>>>>> the secondary user stores as well.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>>>>>>>>>>> Mushthaq
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Wed, Aug 7, 2019 at 3:28 PM Harsha Kumara <
>>>>>>>>>>>>>>>>>>>> hars...@wso2.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> What happen if the role is from secondary user store?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Wed, Aug 7, 2019 at 3:24 PM Naduni Pamudika <
>>>>>>>>>>>>>>>>>>>>> nad...@wso2.com> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> We are planning to add a REST API endpoint to APIM
>>>>>>>>>>>>>>>>>>>>>> 3.0 Publisher Rest APIs and the intention is to check 
>>>>>>>>>>>>>>>>>>>>>> the existence of a
>>>>>>>>>>>>>>>>>>>>>> particular role name. This will be used in order to 
>>>>>>>>>>>>>>>>>>>>>> manage roles when
>>>>>>>>>>>>>>>>>>>>>> enabling Publisher Access Control and Store Visibility 
>>>>>>>>>>>>>>>>>>>>>> and when adding
>>>>>>>>>>>>>>>>>>>>>> Scopes.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The swagger definition for the new endpoint would be
>>>>>>>>>>>>>>>>>>>>>> as follows.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> ######################################################
>>>>>>>>>>>>>>>>>>>>>> # The Role Name Existence
>>>>>>>>>>>>>>>>>>>>>> ######################################################
>>>>>>>>>>>>>>>>>>>>>>   /roles/{roleName}:
>>>>>>>>>>>>>>>>>>>>>> #-----------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>> # The role name existence check resource
>>>>>>>>>>>>>>>>>>>>>> #-----------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>>     head:
>>>>>>>>>>>>>>>>>>>>>>       security:
>>>>>>>>>>>>>>>>>>>>>>         - OAuth2Security:
>>>>>>>>>>>>>>>>>>>>>>             - apim:api_view
>>>>>>>>>>>>>>>>>>>>>>       summary: |
>>>>>>>>>>>>>>>>>>>>>>         Check given role name is already exist
>>>>>>>>>>>>>>>>>>>>>>       description: |
>>>>>>>>>>>>>>>>>>>>>>             Using this operation, you can check a
>>>>>>>>>>>>>>>>>>>>>> given role name is already used. You need to provide the 
>>>>>>>>>>>>>>>>>>>>>> role name you want
>>>>>>>>>>>>>>>>>>>>>> to check.
>>>>>>>>>>>>>>>>>>>>>>       parameters:
>>>>>>>>>>>>>>>>>>>>>>         - $ref : '#/parameters/roleName'
>>>>>>>>>>>>>>>>>>>>>>       responses:
>>>>>>>>>>>>>>>>>>>>>>         200:
>>>>>>>>>>>>>>>>>>>>>>           description: |
>>>>>>>>>>>>>>>>>>>>>>             OK.
>>>>>>>>>>>>>>>>>>>>>>             Requested role name is returned.
>>>>>>>>>>>>>>>>>>>>>>         404:
>>>>>>>>>>>>>>>>>>>>>>           description: |
>>>>>>>>>>>>>>>>>>>>>>             Not Found.
>>>>>>>>>>>>>>>>>>>>>>             Requested role name does not exist.
>>>>>>>>>>>>>>>>>>>>>> ######################################################
>>>>>>>>>>>>>>>>>>>>>> # Role Name
>>>>>>>>>>>>>>>>>>>>>>   roleName:
>>>>>>>>>>>>>>>>>>>>>>     name: roleName
>>>>>>>>>>>>>>>>>>>>>>     in: path
>>>>>>>>>>>>>>>>>>>>>>     description: |
>>>>>>>>>>>>>>>>>>>>>>       The role name
>>>>>>>>>>>>>>>>>>>>>>     required: true
>>>>>>>>>>>>>>>>>>>>>>     type: string
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> It is a HEAD method (*/roles/{roleName}*) which will
>>>>>>>>>>>>>>>>>>>>>> return a 200 status code if the given role name exists 
>>>>>>>>>>>>>>>>>>>>>> and a 404 status
>>>>>>>>>>>>>>>>>>>>>> code if the give role name is not found. Sample requests 
>>>>>>>>>>>>>>>>>>>>>> and responses are
>>>>>>>>>>>>>>>>>>>>>> given below.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Request:
>>>>>>>>>>>>>>>>>>>>>> HEAD
>>>>>>>>>>>>>>>>>>>>>> https://localhost:9443/api/am/publisher/v1.0/roles/valid-role
>>>>>>>>>>>>>>>>>>>>>> HTTP/1.1
>>>>>>>>>>>>>>>>>>>>>> Authorization: Bearer
>>>>>>>>>>>>>>>>>>>>>> ae4eae22-3f65-387b-a171-d37eaa366fa8
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Response:
>>>>>>>>>>>>>>>>>>>>>> HTTP/1.1 200 OK
>>>>>>>>>>>>>>>>>>>>>> Connection: keep-alive
>>>>>>>>>>>>>>>>>>>>>> Content-Length: 0
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Request:
>>>>>>>>>>>>>>>>>>>>>> HEAD
>>>>>>>>>>>>>>>>>>>>>> https://localhost:9443/api/am/publisher/v1.0/roles/invalid-role
>>>>>>>>>>>>>>>>>>>>>> HTTP/1.1
>>>>>>>>>>>>>>>>>>>>>> Authorization: Bearer
>>>>>>>>>>>>>>>>>>>>>> ae4eae22-3f65-387b-a171-d37eaa366fa8
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Response:
>>>>>>>>>>>>>>>>>>>>>> HTTP/1.1 404 Not Found
>>>>>>>>>>>>>>>>>>>>>> Connection: keep-alive
>>>>>>>>>>>>>>>>>>>>>> Content-Length: 0
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Are we good to have the endpoint definition as this?
>>>>>>>>>>>>>>>>>>>>>> Appreciate your inputs to proceed further.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>> Naduni
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> *Naduni Pamudika* | Senior Software Engineer | WSO2
>>>>>>>>>>>>>>>>>>>>>> Inc.
>>>>>>>>>>>>>>>>>>>>>> (m) +94 (71) 9143658 | (w) +94 (11) 2145345 | (e)
>>>>>>>>>>>>>>>>>>>>>> nad...@wso2.com
>>>>>>>>>>>>>>>>>>>>>> [image: http://wso2.com/signature]
>>>>>>>>>>>>>>>>>>>>>> <http://wso2.com/signature>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> *Harsha Kumara*
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Technical Lead, WSO2 Inc.
>>>>>>>>>>>>>>>>>>>>> Mobile: +94775505618
>>>>>>>>>>>>>>>>>>>>> Email: hars...@wso2.coim
>>>>>>>>>>>>>>>>>>>>> Blog: harshcreationz.blogspot.com
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> GET INTEGRATION AGILE
>>>>>>>>>>>>>>>>>>>>> Integration Agility for Digitally Driven Business
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> Mushthaq Rumy
>>>>>>>>>>>>>>>>>>>> *Senior Software Engineer*
>>>>>>>>>>>>>>>>>>>> Mobile : +94 (0) 779 492140
>>>>>>>>>>>>>>>>>>>> Email : musht...@wso2.com
>>>>>>>>>>>>>>>>>>>> WSO2, Inc.; http://wso2.com/
>>>>>>>>>>>>>>>>>>>> lean . enterprise . middleware.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> <http://wso2.com/signature>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Mushthaq Rumy
>>>>>>>>>>>>>>>>>>> *Senior Software Engineer*
>>>>>>>>>>>>>>>>>>> Mobile : +94 (0) 779 492140
>>>>>>>>>>>>>>>>>>> Email : musht...@wso2.com
>>>>>>>>>>>>>>>>>>> WSO2, Inc.; http://wso2.com/
>>>>>>>>>>>>>>>>>>> lean . enterprise . middleware.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> <http://wso2.com/signature>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *Harsha Kumara*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Technical Lead, WSO2 Inc.
>>>>>>>>>>>>>>>>>> Mobile: +94775505618
>>>>>>>>>>>>>>>>>> Email: hars...@wso2.coim
>>>>>>>>>>>>>>>>>> Blog: harshcreationz.blogspot.com
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> GET INTEGRATION AGILE
>>>>>>>>>>>>>>>>>> Integration Agility for Digitally Driven Business
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Malintha Amarasinghe
>>>>>>>>>>>>>>>>> *WSO2, Inc. - lean | enterprise | middleware*
>>>>>>>>>>>>>>>>> http://wso2.com/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Mobile : +94 712383306
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *Harsha Kumara*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Technical Lead, WSO2 Inc.
>>>>>>>>>>>>>>>> Mobile: +94775505618
>>>>>>>>>>>>>>>> Email: hars...@wso2.coim
>>>>>>>>>>>>>>>> Blog: harshcreationz.blogspot.com
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> GET INTEGRATION AGILE
>>>>>>>>>>>>>>>> Integration Agility for Digitally Driven Business
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Malintha Amarasinghe
>>>>>>>>>>>>>>> *WSO2, Inc. - lean | enterprise | middleware*
>>>>>>>>>>>>>>> http://wso2.com/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Mobile : +94 712383306
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> *Bhathiya Jayasekara* | Technical Lead | WSO2 Inc.
>>>>>>>>>>>>>> (m) +94 71 547 8185  | (e) bhathiya-@t-wso2-d0t-com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> *Naduni Pamudika* | Senior Software Engineer | WSO2 Inc.
>>>>>>>>>>>>> (m) +94 (71) 9143658 | (w) +94 (11) 2145345 | (e)
>>>>>>>>>>>>> nad...@wso2.com
>>>>>>>>>>>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>>
>>>>>>>>>>>> *Menaka Jayawardena*
>>>>>>>>>>>> Senior Software Engineer | WSO2 Inc.
>>>>>>>>>>>> +94 71 350 5470 | +94 76 717 2511 | men...@wso2.com
>>>>>>>>>>>>
>>>>>>>>>>>> <https://wso2.com/signature>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Malintha Amarasinghe
>>>>>>>>>>> *WSO2, Inc. - lean | enterprise | middleware*
>>>>>>>>>>> http://wso2.com/
>>>>>>>>>>>
>>>>>>>>>>> Mobile : +94 712383306
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> *Sanjeewa Malalgoda*
>>>>>>>>>> Software Architect | Associate Director, Engineering - WSO2 Inc.
>>>>>>>>>> (m) +94 712933253 | (e) sanje...@wso2.com | (b) Blogger
>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com>, Medium
>>>>>>>>>> <https://medium.com/@sanjeewa190>
>>>>>>>>>>
>>>>>>>>>> GET INTEGRATION AGILE <https://wso2.com/signature>
>>>>>>>>>> Integration Agility for Digitally Driven Business
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> *Naduni Pamudika* | Senior Software Engineer | WSO2 Inc.
>>>>>>>>> (m) +94 (71) 9143658 | (w) +94 (11) 2145345 | (e) nad...@wso2.com
>>>>>>>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Vithursa Mahendrarajah
>>>>>>>> Software Engineer
>>>>>>>> WSO2 Inc. - http ://wso2.com
>>>>>>>> Mobile  : +947*66695643* <+94%2077%20819%201300>
>>>>>>>>
>>>>>>>>
>>>>>>>> * <http://wso2.com/signature> <http://wso2.com/signature>
>>>>>>>> <http://wso2.com/signature>*
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> *Harsha Kumara*
>>>>>>>
>>>>>>> Technical Lead, WSO2 Inc.
>>>>>>> Mobile: +94775505618
>>>>>>> Email: hars...@wso2.coim
>>>>>>> Blog: harshcreationz.blogspot.com
>>>>>>>
>>>>>>> GET INTEGRATION AGILE
>>>>>>> Integration Agility for Digitally Driven Business
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Vithursa Mahendrarajah
>>>>>> Software Engineer
>>>>>> WSO2 Inc. - http ://wso2.com
>>>>>> Mobile  : +947*66695643* <+94%2077%20819%201300>
>>>>>>
>>>>>>
>>>>>> * <http://wso2.com/signature> <http://wso2.com/signature>
>>>>>> <http://wso2.com/signature>*
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Vithursa Mahendrarajah
>>>>> Software Engineer
>>>>> WSO2 Inc. - http ://wso2.com
>>>>> Mobile  : +947*66695643* <+94%2077%20819%201300>
>>>>>
>>>>>
>>>>> * <http://wso2.com/signature> <http://wso2.com/signature>
>>>>> <http://wso2.com/signature>*
>>>>>
>>>>
>>>
>>> --
>>> *Bhathiya Jayasekara* | Technical Lead | WSO2 Inc.
>>> (m) +94 71 547 8185  | (e) bhathiya-@t-wso2-d0t-com
>>>
>>>
>>>
>>
>> --
>>
>> *Harsha Kumara*
>>
>> Technical Lead, WSO2 Inc.
>> Mobile: +94775505618
>> Email: hars...@wso2.coim
>> Blog: harshcreationz.blogspot.com
>>
>> GET INTEGRATION AGILE
>> Integration Agility for Digitally Driven Business
>>
>
>
> --
> *Bhathiya Jayasekara* | Technical Lead | WSO2 Inc.
> (m) +94 71 547 8185  | (e) bhathiya-@t-wso2-d0t-com
>
>
>

-- 

*Harsha Kumara*

Technical Lead, WSO2 Inc.
Mobile: +94775505618
Email: hars...@wso2.coim
Blog: harshcreationz.blogspot.com

GET INTEGRATION AGILE
Integration Agility for Digitally Driven Business
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to