Hi All,
In Oauth /token endpoint and /revoke endpoint
https://localhost:9443/oauth2/token
https://localhost:9443/oauth2/revoke
required authorization with client key, client secret in basic auth
headers. Currently in implementation we validate those headers after
serving request to JAX-RS endpoi
The type of events we're talking about here are rare events. API creation,
subscription, etc won't happen that frequently. So I don't think there will
be much load on the broker as such.
Architecturally having separate topics will be clean. The code and the
error handling parameters (dead letter q
I am +1 with option 2 but not with separate topics for each and every event
types. Like you have suggested we can have separation like API publisher,
API store events. It will give a clean architectural view and we can have
clean gateway logic for each event types.
On Tue, Apr 25, 2017 at 11:09 AM
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 8:46 AM, Harsha Thirimanna wrote:
>
>
> On 21 Apr 2017 3:35 p.m., "Asela Pathberiya" wrote:
>
> Hi IS/APIM team,
>
> Is $subject in our roadmap ?
>
> We will add this to the roadmap.
>
> This seems to be a required features. Different applications may need the
> differen
Hi All,
According to APIM C5 architecture, the events like API create, API
lifecycle status change, API subscriptions are notified to APIM gateway via
JMS topic/topics in the broker.
Following diagram depicts how APIM core, broker and gateway components
interact when there is an event generated f
Hi all
We are planning to add redirection support for workflow tasks to API
Manager C5 (This feature was in C4 and used to plug in external billing
engine for subscription). Following will be the suggested plan to implement
it
In previous version of AM (see [1][2] for additional information), for
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
On 21 Apr 2017 3:35 p.m., "Asela Pathberiya" wrote:
Hi IS/APIM team,
Is $subject in our roadmap ?
We will add this to the roadmap.
This seems to be a required features. Different applications may need the
different user token expiry time based on their security level.
Yes, it seems the ap
WSO2 Message Broker team is pleased to announce the release of WSO2 Message
Broker 3.2.0!
WSO2 Message Broker is a 100% open source, distributed, highly scalable,
portable, and interoperable product that supports JMS, AMQP and MQTT
standards for enterprise messaging and can be used in scenarios wh
On Fri, Apr 21, 2017 at 2:05 PM, Sanjeewa Malalgoda
wrote:
> As i know oauth 2.0 spec doesn't say anything about validity period per
> dynamic client registered in the system. And if DCR endpoint accept
> optional parameters then we can send application default validity period
> along with DCR re
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
15 matches
Mail list logo
