WSo2 Governance Registry - rest

I am evaluating WSO2 for our SOA governance solution. Few questions
It provides a way to document services. Is there a way to document each operations listed in WSDL or resources of a RESTful service? I am not able to find this information.
How do I provide information about RESTful services?
Is there a policy enforcement?
Thanks for all the responses. I did look at API manager. Looks good but have couple of questions
I couldn't find a way to document endpoints for various environments. only 2 URLs supported - for sandbox and for production. How can I provide url for more environments?
Is it possible to customize lifecycle?

and 2. You can define your own metadata this means you can store any data (the new data types are defined via XMLs which you upload to the server), there is a tutorial by the wso2 team with an example on how to do that.
I'm afraid I don't get what you mean in 3. Do you want different users to be able to create different type of artifacts?
This is a tutorial I've found useful: http://www.youtube.com/watch?v=pXfxiZlOtH0
You can also find documentation on the wso2 website

To me it sounds like you might want to have a look at Wso2 API Manager 1.0, in fact it provides a nice interface to write your documentation for APIs in the 'publisher' side.
Also you will have all the information the user needs to consume the Restful Service + an API key to Authenticate in the 'store' side of the API Manager.
You will not have to worry about G-Reg because the API manager already include one and allows you to easily govern your SOA services.
Hope this helps

In SOA deployment, you can use WSO2 ESB as the PEP (Policy Enforcement Point).
Please follow this article for more details. In that kind of deployment you can use mounted WSO2 Governance Registry server as a policy store. That will facilitate you to maintain the service policies in central repository and governance capabilities like Versioning, Life cycle management, Notifications...etc.

Related

JWT authentication for jBASE RESTful API

We are in the process of designing a front-end application with Angular which will call a jBASE server through RESTful APIs. APIs are created from jBASE component called jAgent.
Does jAgent support creating and verifying JWTs?
If not, what is the best way to handle authentication/authorization for the Angular application?
If we need to use JWTs, do we have to use a authentication middleware application (.NET Core or node.js) for that?
Great question! At the moment there is no handler within jAgent and our recommendation is to implement this, and advanced web server/API gateway technology by way of other applications like HAproxy or Kong.
An expansion of jAgent functionality to include things like this is something we're still considering but keep in mind, the power of jBASE lies in its native interactions with the host OS. Since there is no virtual OS layer it can be easier to plug and play off the shelf things to fill in for additional functionality, which gives you the flexibility to bring your own tooling.
In summary:
Not at the moment
Using an off the shelf package to act as your API gateway
Subject to the package you choose
That relegates jAgent to management of the API layer as it exists on the PICK/jBASE side while the off the shelf package manages your API security layer.
One other note for you--I noticed that you included a link to the old jBASE docs hosted on HelpJuice. It's worth mentioning that we've migrated those docs to docs.zumasys.com. You'll find the docs there to be more up to date, and also completely open sourced--part of the migration included their move to a GitHub repo, where we're happy to take community contributions.
For reference, the article you mentioned is available at https://docs.zumasys.com/jbase/connectivity/jagent/introduction-to-jagent-rest-services/.
Update:
One of our engineers has a program that will use openssl to generate the tokens for you, which you can find at https://github.com/patrickp/wjwt.
You will need openssl installed on the machine and in the path.
The WJWT.TEST program shows the usage. The important piece is the SECRET.KEY which is your internal KEY you use to sign the payloads.
When a user first authenticates you create the token with SIGN. Claims are any items/fields you wish to save/store. Do NOT put sensitive data in here as it is viewable by anybody. The concept is we sign this with our key, give it back to the client. On future calls the client sends the token and we pull it and call the VERIFY function which basically re-signs the payload and validates the signatures match. This validates the payload was not manipulated.
Activities such as expiration you would build into your code.
Long term we plan to take this library and refactor the code into our MVDB Toolkit library with more functionality. That library is something we provide to jBASE customers at no additional charge.

What can I use as a XACML PDP?

I have an API REST made in node js, and now I'd like to implement some XACML policy. I have been searching and I found that I can use ALFA to make the XACML rules. But I need a PDP for applying the rules. What can I use / how can I implement it?
I have read about WSO2 Identity Server (which I think I can use as a PDP? I'm not sure). It is probably too much for a little project. Any other suggestions? Or is WSO2 IS adecuate?
The go-to open source implementation of XACML 3.0 nowadays is AuthZForce. In OSS, it's the most up-to-date. In the commercial realm, look into Axiomatics (where I worked). They have the most up-to-date PDP and are the authors of the standard.
Yes, you can use Wso2 Identity Server as your PDP. Once I had a requirement to secure a Spring Boot rest API through XACML[1]. Anyway, It would be much easier for you to use the Identity Server PDP than implementing one. You have easy beginner samples that you can try out for your use case.[2] There are tools in the identity server that you can use to create the XACML rules.
[1].https://medium.com/#buddhimau/role-based-authorization-for-spring-boot-using-wso2-identity-server-3d74ab307fb9
[2].https://medium.com/#gdrdabarera/how-entitlement-management-works-with-rest-api-via-xacml-in-wso2-identity-server-5-3-0-7a60940d040c
Adding to Buddhima Udaranga reply, If you think IS too much for a little project, then you can directly use balana, which is the entitlement engine used inside IS. You can refer to this for more details. But balana have only java API.

Designing REST API for Different Consumers

I have an application API that is used In two scenarios:
My frontend application uses it to interact with the server
A client is using it for development of CLI tool so there is an open documentation of the API.
At start all of the endpoints were kind of generic so they have been used in both scenarios, but as my application grows i have a need to :
create special endpoints for my frontend application for optimization, for example an endpoint to some statistics screen
Change some of the basic API results structures that are not backward compatible and can break the Clients
usage.
What is the best practice to design an API to meet these needs?
How is should be design correctly so it will be adjusted
to the frontend needs and on the other side will be robust enough to not break the Client's applications?
frontend specific endpoints along with General ones?
What is the best practice to design an API to meet these needs?
This highly depends on your scenario. Is your API going to be used internally only or will it be made publicly available to an unknown number of developers and integrators? What is the expected lifetime of the API? Will it evolve?
How is should be design correctly so it will be adjusted to the frontend needs and on the other side will be robust enough to not break the Client's applications?
I recommend to commit to API contracts and use a specification for these contracts. I prefer the OpenAPI specification as it will come with a lof of benefits. Make sure you invest a lot of time and team effort (product owner, project managers, backend & frontend devs) to develop the contract in several iterations. After each iteration test the specification by mocking the API and clients before turning over to to implement your frontend app or cli client.
frontend specific endpoints along with General ones?
I would not do that, but I do not know you context. What does a frontend specific endpoint mean? If it means that as of today the endpoint should be only used by the frontend application but is of no use for the current cli client than I think it is just a matter of perspective. Make it a general endpoint and just use it by the frontend app. If it somewhat provides sensitive information that should be access only by the frontend you need to think about authentication and authorization. I recommend implementing Oauth2 for that.
create special endpoints for my frontend application for optimization, for example an endpoint to some statistics screenfrontend specific endpoints along with General ones?
I would suggest to implement all endpoints in your API and use OAuth2 as authentication. Use the scopes of the OAuth approach to manage authorization and access to different endpoints for each client (frontend app, cli).
You wrote you need to:
Change some of the basic API results structures that are not backward compatible and can break the Clients usage.
Try to avoid making breaking changes to your API. If it is used internally only you may be in control of the different clients accessing the API but even than the risk of breaking a client is high.
If you need to change existing behaviour you should think about API versioning or API evolution, which is a controversly discussed topic with a lot of different opinions and practices.
What is the best practice to design an API to meet these needs?
Design your resource representations so that they are forward and backwards compatible by design. Fundamentally, they are messages, so treat them that way; new optional fields with reasonable defaults can be added to the messages, but the semantics of a message element should never change.
If you dig through the old XML literature, you'll find references to ideas like Must Ignore and Must Forward -- those are the sorts of princples that also apply to the representations of long lived resources.
Create new resources when the existing resources cannot be conveniently extended to cover your new use case.

Visual REST API playground

What are some web apps that allow me to play with any REST APIs visually (by clicking) and also get some code generated (in any language) that captures what I have described visually?
Similar to Swagger or Google API Playground but allows me to talk to anything that speaks REST (assuming I have the proper auth credentials and I know what messages it understands).
Bonus points for something that can also "discover" what messages are understood, given a URL endpoint.
Microsoft has 2 that I know of
OData API explorer
The data market service explorer (requires signing in, and then you can access free data sets)
Considering that REST API's are going to follow their own conventions, terms, and have their own documentation (hopefully), this is an impossible problem. If you restrict your quest to visualizing API's that follow a "standard" form of self-documentation (see REST web service WSDL? for some hopeful scenarios) you might be able to accomplish this.
Or you can use something like http://www.programmableweb.com/ to discover tutorials, tools, examples, and mashups of various existing APIs.
You could mock an API at http://apiary.io/.
You could explore and existing one through tools (e.g. REST Console for Chrome)
What you can't have, is one-size-fits-all explorer for "every possible REST API." Some APIs follow conventions that others don't.
apigee and apihub (now part of mulesoft) are two that I frequently visit. Of the two, apigee is my preferred provider.
One of the reasons that you're not going to see a lot of websites like this is because of the same-origin policy. This means that you can't access a RESTful API located at api.google.com from a web app running at, say, www.restfiddle.com without sending all the API traffic through restfiddle.com's servers. Sites like JSFiddle can exist (and are used widely) because all the processing is done on the client side.
Browser plugins, however, are exempt from the same-origin policy. If you're using Chrome, try Postman. If your REST client doesn't need to be web-based, check out SoapUI. IntelliJ IDEA has a nice REST client as well.
Try Restlet Studio, it's the only visual API designer I've found, and seems pretty good, it imports and exports swagger & RAML.
http://studio.restlet.com/

What the alternative for UDDI Repository?

Dose RESTful services have some repository like UDDI for Web service?
Please tell me the URL for resist the service.
If you are looking for standards, the SOA Repository Artifact Model and Protocol is basically a REST-ful replacement for UDDI. It is based upon the AtomPub protocol.
If you are looking for products, there are plenty of tools out there that will work. I have used WSO2 Governance Registry in the past with good results.
There is no such service I know of.
Besides, I don't know of any usable UDDI repository, too.