I have set up wso2 Identity server 5.3.0 with my web applications. Its working smooth for less number of policies and roles. As soon as number of policy and roles are getting increased the getDecision method from EntitlementService web service. Even worst thing is sometimes its giving time out.
Ant lead, How to improve getDecision method performance or caching ?
Let me know if you need other information below in the comment.
#Mak you can use XACML policy caching technique to improve the performance. Please refer below document to improve the performance.
https://docs.wso2.com/display/IS550/Improving+XACML+PDP+Performance+with+Caching+Techniques
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Being the cheap-o that I am, I had an idea the other day of running a web app for less than a nickel per month with AWS:
Serve a static site (html/css/javascript) via S3
Client-side code and forms post to Lambda golang microservices via API Gateway
Use DynamoDB (25 read/s, 25 write/s, 25GB, 1GB/mo in, 1GB/mo out) as database
Would this scheme work with say, cookie and sesssion-based authentication, as the page is being served by one domain name (S3), but the javascript is talking to another domain name (API Gateway)?
What other issues am I likely to run into?
Mike Roberts wrote a very thorough article on serverless architecture and its trade-offs: http://martinfowler.com/articles/serverless.html
Also discovered a framework designed for precisely this which runs on AWS: https://serverless.com/
However, it appears at this time, persistent connections (e.g. websockets) are not supported, which is a deal-breaker for me. I suspect AWS will eventually let API Gateway service the websocket and send its messages to Lambda, but as of today this does not appear to be possible.
I run multiple web apps exactly with your proposed design, and I extracted gofaas, an educational Go and Lambda app, to share the techniques.
Setting a cookie for the static site client is possible with CloudFront and a Lambda#Edge auth function.
Allowing the static site to talk to the API is possible with an API Gateway CORS configuration.
Finally this relies on JSON Web Tokens (JWT) to securely represent an authorization claim between your user, your static site and your API.
Here are some guides for setting all this up:
Static Website Security with Lambda#Edge and Google OAuth 2
API Security with Lambda, API Gateway, CORS and JWT
One of the things to keep in mind with 'serverless' architectures is:
"What happens if 'this thing' really takes off?"
Most people don't consider how high requests rates for Lambda or DynamoDB can get when your site becomes super popular, or is under a DDOS attack.
Like your request rates, your total charges will also see a significant spike during these events. So for "small projects" where low cost really is important I usually advise sticking some some small VMs to handle processing. While high request rates or a DDOS may overwhelm and take down your service, you likely won't be hit with an outrageous bill.
While serverless is very convenient for getting setup, it can very easily bite back much harder than expected.
Note: If you do find yourself in a situation where your bill is higher than expected, reach out to your cloud provider. Some of them maybe willing to help you with a one time credit for some portion of the charges depending on the circumstances.
But be prepared to explain what happened in detail. I also advise having service logs (not just for your applications), but also for any cloud services which you are using.
I clustered APIM with 1 manger gateway node and 2 or more work node to test APIM response time.
it did not give me good data.
without APIM,my api response time is 20 ms.though APIM 400ms-1s.
how to confige this question?
There are several handlers in APIM, through which all API calls are going. Eg. Authentication, Throttling, CORS etc.
You can enable analytics in APIM and see a latency breakdown graph among stages. See Figure 9 of this article. Then you can identify if there are any handlers which cause a large latency. Then we can decide how to fix that.
in order to slove my problem,i find all bolgs.
finally ,in this blog,Sanjeewa Malalgoda give a solution.
Then,after my test,the result is effiective.
I am trying to benchmark WSO2 identity server 4.5, using postgresql, to measure how many policies can be supported without having a too bad decision time.
I have java program to upload all my policies using EntitlementPolicyAdminServiceStub from org.wso2.carbon.identity.entitlement.stub-4.2.0.jar:
adminStub.addPolicy(myPolicy)
After the 100 first policies there is an important degradation of upload time (more than 2 sec for each policy) and it gets worse with time.
For 3000 policies, WSO2 is no more responsive and, when I have a look to database statistics I can see there are more than 10^12 Tuples Returned for the all the database and 10^11 Sequential Tuples Read for the reg_resource_property table.
Is it something normal or is there a mistake in my WSO2 configuration?
Yes.. there can be some limit.. In your case, it seems to be an issue with policy storing.. By default identity server stores XACML policies in the wso2 registry.. You could see such database statistics due to that.. Because it is not like just putting policy as a database entry in a table.. As it is governance registry, there are lot things happened behind that... If you need more performance with policy storing, I guess it is better to implement a new policy store by extending the default behavior. Basically you can write a policy store to persist policies in a simple database table or even in file system. You can find the source of the Registry policy store from here.
Also, In runtime, all policies are loaded in to the memory, normally this is happened when entitlement engine is initialized.. or less any update is happened.. When number of policies are large there can be delay in retrieving policies from registry (but registry itself as caching and indexing...so may be not as slow as we think). As runtime, all policies are kept in the memory, we may need to consider about the memory footprint of the server. You can increase it using wso2server.sh file.
Also, there are some doc that has been mentioned about performance test with WSO2IS, Please refer it for more details
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I would like to know the differences between Mashery, WSO2 and 3scale. Someone who has used API Managers before can give his opinion? What are advantages and disadvantages of each one
thanks
cheers
Not sure, but this question might end up flagged as off topic - vendor comparison, but anyway I'll jump in. I work at 3scale (full disclosure) but hopefully this is useful anyway - the three are pretty different. Trying to be as neutral as possible!:
3scale uses NGNIX and/or open source code plugins to enforce all of the API traffic rules and limits (rate limits, key security, oauth, analytics, switching apps on and off etc.) and the traffic always flows directly to your servers (not via the cloud) so you don't have additional latency or privacy concerns. Because it's NGNIX it's also widely supported, very fast and flexible. Then it has a SAAS backend that manages all the analytics, rate limits, policies, developer portal, alerts etc. + synchronizes across all the traffic manager nodes. It's free to use up to nearly 5million API calls per month.
WSO2's system is an additional module to the WSO2 ESB so if you're using that it makes a lot of sense. It runs everything locally with no cloud components - a pro or a con depending on how you see it. It's also been around a lot less time and doesn't have such a large userbase.
Mashery has two systems - the main one with which the API traffic flows through Mashery's cloud systems first and has traffic management applied there. So there is always a latency heavy roundtrip between the users of the API and your servers + it means Mashery is in your API traffic critical path. They also have an on premise traffic manager but it's much less widely used. Both solutions have very significant costs and long term commitments.
As 3scale what we see as the main advantage is you have a tons of control as to how you set up all the traffic flow and never have to route through a third party plus you have the benefit if having all the heavy lifting hosted and synchronized across multiple data centers. We're also committed to having a strong free for ever tier of service since we want to see a lot of APIs out there! http://www.3scale.net/
Good luck with your choice!
steve.
I'm trying to choose one of forgerock identity management solution (openAM, openIDM) and wso2 identity server for implementing Identity and Access Management solution.
I'm interested in using following features:
Single Sign-On (SSO)
Policy based access control
Managing user identities
Connecting to central repository like Active Directory, OpenLdap, Oracle Internet Directory etc.
Etc..
Both open source products looks viable. I'm interested in having all of the above features along with good API to implement these features, along with active community support.
Which one would be the best amongst two ?
Thanks.
I am an architect from WSO2 - mostly leading WSO2 Identity Server. I am trying to be not bias as much as possible :-)
Both products bring you a comprehensive Identity Management platform - having support for SAML2, OpenID, XACML 3.0, OAuth 2.0, SCIM, WS-Security standards.
Few unique features that I would like to highlight on WSO2 Identity Server are...
Decentralized Federated SAML2 IdPs (http://blog.facilelogin.com/2012/08/security-patterns-decentralized.html)
Distributed XACML PDPs
User friendly XACML PAP wizard
High scalability (We have a middle-east customer using WSO2 IS over an user base of 4 million for OpenID support.)
Cassandra based User Store ( To be used over 800 Million user base by one of our production customers)
Light-weight and Very low memory footprint. The stripped down version of WSO2 IS can be started with 64MB Heap Size and the standard versions runs with 96MB Heap.
Highly extensible. The architecture behind WSO2 IS is highly extensible. You can easily plugin your authenticators, user store, etc...
Support for multi-tenancy.
Suport for multiple user stores (AD, LDAP, JDBC)
Interoperability.
Part of a proven SOA product platform provided by WSO2.
Also, we are planning to add support for OpenID Connect this year with a set of improved Identity Management capabilities.
You can also read more about WSO2 Identity Server from http://blog.facilelogin.com/2012/08/wso2-identity-server-flexible.html
You will not get an unbiased answer from me for your question :-) "Which one would be the best amongst two ?". You will aso get answers from Forgerock and other folks here. Best would be to evaluate and decide.
I'm a product manager at ForgeRock, but not for the products you're mentioning (OpenAM, OpenIDM).
ForgeRock Open Identity Stack has complete support for all your requirements, based on existing standards such as the ones mentioned by Prabath. It presents a single, common REST API to interact across the platform.
It's easy to deploy, modular, lightweight and yet highly extensible.
But in my opinion the key point is that it's a proven solution, deployed by hundreds of organizations, with built-in internet scale. The solution has been chosen by telecom service providers, medium and large enterprises for internal or customer facing services.
And I agree with Prabath, now that you've got answers from ForgeRock and WSO2, best would be to evaluate and make your own decision.
Regards.
Ludovic.
I am currently evaluating WSO2. It has a more permissive APACHE LICENSING Model and a more friendly management model from my having met with ForgeRock people.
Abdul, please share your findings as I am looking at both as well. We implemented OpenSSO in production a couple years ago just prior to its transition to OpenAM. It was an excellent product with thought leadership and decent execution. Unfortunately the pending transition to OpenAM was too unnerving for some of us and we switched to another product at great, unnecessary cost and continue to look over our shoulder. Some downsides at the time were ability to migrate policy through lanes from dev-test-stage-prod, keeping configurations in sync, and issue resolution. Also, fine-grained policy was very new. So my info is a bit dated and I know they have matured since then.
Just starting with WSO2. It has strong thought leadership and good execution with several platforms per other reviews. Their base architecture looks solid and it's allowing them to create and consume/improve open source technology very quickly into integrated, commercially supported solutions.