On Tue, Apr 25, 2017 at 1:11 PM, Ishara Karunarathna
wrote:
> HI,
>
> On Tue, Apr 25, 2017 at 11:21 AM, Nuwan Dias wrote:
>
>> Yes, maintaining the mappings is not an issue AFAIS. The API definition
>> (Swagger) itself has the scope associated with each resource. So we just
>> need a way of stor
HI,
On Tue, Apr 25, 2017 at 11:21 AM, Nuwan Dias wrote:
> Yes, maintaining the mappings is not an issue AFAIS. The API definition
> (Swagger) itself has the scope associated with each resource. So we just
> need a way of storing the role(s) against each scope. By default the
> product will have
Yes, maintaining the mappings is not an issue AFAIS. The API definition
(Swagger) itself has the scope associated with each resource. So we just
need a way of storing the role(s) against each scope. By default the
product will have like say <10 scopes. So what we're looking at is a config
with the
On Tue, Apr 25, 2017 at 9:43 AM, Nuwan Dias wrote:
> What's wrong with using OAuth2.0 scopes? The authorization requirements
> are simply to define which role/group is permitted to access a given
> resource. Which is very simply supported OOTB via scopes and the
> configuration is very simple as
Hi Ishara,
On Thu, Apr 20, 2017 at 11:08 AM, Ishara Cooray wrote:
> Hi,
>
> Previous versions(Before C5) of APIM Publisher, Store Apps front end
> validations were done based on user roles.
>
> But with C5 we think of fine graining User Interfaces by controlling
> access to UI components such as
What's wrong with using OAuth2.0 scopes? The authorization requirements are
simply to define which role/group is permitted to access a given resource.
Which is very simply supported OOTB via scopes and the configuration is
very simple as well.
One of the key design principles here is to keep thing
On 21 Apr 2017 5:27 p.m., "Asela Pathberiya" wrote:
On Fri, Apr 21, 2017 at 4:46 PM, Ishara Cooray wrote:
> Hi Asela,
>
> What is reason for using scopes for authorization.. ? Can't we use policy
> based approach such as XACML ?
>
> Default authentication and authorization protocol we use is
Hi Ishara,
On Thu, Apr 20, 2017 at 11:08 AM, Ishara Cooray wrote:
> Hi,
>
> Previous versions(Before C5) of APIM Publisher, Store Apps front end
> validations were done based on user roles.
>
> But with C5 we think of fine graining User Interfaces by controlling
> access to UI components such as
On Fri, Apr 21, 2017 at 4:46 PM, Ishara Cooray wrote:
> Hi Asela,
>
> What is reason for using scopes for authorization.. ? Can't we use policy
> based approach such as XACML ?
>
> Default authentication and authorization protocol we use is oauth, hence
> we already have support for scopes in ou
Hi Asela,
What is reason for using scopes for authorization.. ? Can't we use policy
based approach such as XACML ?
Default authentication and authorization protocol we use is oauth, hence we
already have support for scopes in our REST APIs.
Therefore is it straight forward to use scopes as we ju
Hi Ishara,
Please see my comments inline.
On Thu, Apr 20, 2017 at 11:08 AM, Ishara Cooray wrote:
> Hi,
>
> Previous versions(Before C5) of APIM Publisher, Store Apps front end
> validations were done based on user roles.
>
> But with C5 we think of fine graining User Interfaces by controlling
>
On Thu, Apr 20, 2017 at 11:08 AM, Ishara Cooray wrote:
> Hi,
>
> Previous versions(Before C5) of APIM Publisher, Store Apps front end
> validations were done based on user roles.
>
> But with C5 we think of fine graining User Interfaces by controlling
> access to UI components such as Add, Edit,
Hi,
Previous versions(Before C5) of APIM Publisher, Store Apps front end
validations were done based on user roles.
But with C5 we think of fine graining User Interfaces by controlling access
to UI components such as Add, Edit, Delete buttons/links based on the user
scopes.
1. We need to find sc
13 matches
Mail list logo
