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.
Related
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.
After successfully implementing SAML-V2 Service Provider (SP); for supporting some specific use-case, I have to implement my own SAML-2 IdP. After going through OASIS Documentation and many others about the SAML protocol, I have started implementing it.
My Use-case is just a single profile (Web Browser SSO Profile) with SP-Initiated SSO: Redirect Bindings only.
I am looking for some lean third-party library or java based implementation which I can refer/use to speed up the implementation and customize on top of that.
Would love for any recommendation or suggestion in this direction.
To be specific I'm looking for any/all of below :
Easy to use open-source library for implementing SAML-V2 Identity Provider in Java.
Detailed documentation/specification for above profile.
Any advice from experts who have past experience in implementation such kind of IdP.
There is lots of material available for SP. However, very few and complex for IdP.
Some of the java-based implementation which I am already looking are : KeyCloak and Lite-IdP.
"Very few and complex" is true because building a real-world identity provider is a serious project. OpenSAML as the library is your best option in Java - many enterprise-grade implementations that we know about are built with it. A good, stripped-down example of how to use OpenSAML in IdP context is https://github.com/OpenConext/Mujina .
Lite IdP is written in Go. If you're open to non-Java options, SimpleSAMLphp is excellent, it's certainly better documented than many others.
I'd post it as comment, but I don't have enough reputation.
But here you have almost the same question, regarding Spring SAML:
using-spring-saml-as-an-idp-rather-than-an-sp
Take a look at Vladimir's answer, I think it's what you're looking for. Here is the link suggested by him.
Cheers
I need to implement Single Sign On feature for several internal web applications which are not deployed on the same domain.
Is federation a good solution in my case? Or it is only used if I want to federate the authentication to an external IdP.
I mean I want to create a custom WIF STS and make all the applications claims-aware RPs.
I'm thinking of it because I don't want to use custom solutions or third party libraries. WIF seems to have a straightforward solution integrated with .Net Framework.
Is my suggestion correct? Or this is an incorrect use for WIF.
Yes - a solution with WIF / STS will work even if it's only internal.
Beware of security if you roll your own.
You may want to look at ADFS or IdentityServer.
Going this route will make your life a lot easier.
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.
For a college project i'm thinking of implementing the business layer in Erlang and then accessing it via multiple front-ends using REST. I would like to avail of OTP features like distributed applications, etc.
My question is how do I expose gen_server calls/casts to other applications? Obviously I could make RPC calls via language specific "bridges" like OTP.net or JInterface, but I want a consistent way to access it like REST.
As already mentioned Yaws or Mochiweb are a great way to go but if you'd like a dead simple way to get your RESTful API done quickly and correctly then use Webmachine. It's a layer on top of Mochiweb that implements proper HTTP behavior based on Alan Dean's amazing HTTP flow diagram and makes it easy to get REST done right.
I'm using it right now to expose a REST API as well as handle a COMET application and it's been pretty easy to do, even for an Erlang newbie such as myself.
I did something similar for my job and found it best to use REST to expose the business layer because even Legacy languages such as SoftwareAG's Natural is able to access it. The best mechanism that I have found in Erlang is to use Mochiweb.
You can find more information about using it from the screencast located at
Erlang In Practice Screencast. Episode 6 is particularly helpful but all of them are excellent.
A resource to walk you through installation is How To Quickly Set Up Ubuntu 8.04 loaded with Erlang, Mochiweb and Nginx and Migrating a native Erlang interface to RESTful Mochiweb (with a bit of TDD) provides a good start if you don't find the screencasts to your liking.
The HTTP flow diagram link is dead. The original version and a updated version created in collaboration between Alan Dean and Justin Sheehy ist also hosted in the Webmachine project: link to latest version of the HTTP Diagramm.
There is valuable approach to design gen_server calls/casts in flavor of REST if possible. You can use messages as
{get, Resource}
{set, Resource, Value} % aka PUT
{delete, Resource}
{add, Resource, Value} % aka POST (possible another names are append, modify or similar)
Then its mapping is easy. You can make some transformation URI->RESOURCE or use identity. For most of your application this should be wort approach and special cases you should handle specially. You can think there will be big margin, where you can't use this approach, but this should be mostly premature optimization.
Do you really mean a RESTful interface or RPC over HTTP? Building a RESTful interface on top of an existing layer is more work than just exposing existing methods via HTTP.
I'd suggest to use mochiweb or yaws to implement a (generic) rpc layer.
Just an update, Webmachine has moved to bitbucket: new link to Webmachine