I want to understand what are the benefits of using Apigee if i already have Layer7 in place? please let me know if which is better and why.
Apigee is a very 'developer friendly' API management platform.
Layer 7 has also API management functions.
With the newest version of Layer7 (spring 2017) the API management functions have improved drastically.
Older version of Layer7
If you have (an older version) of the Layer7 platform running in order to create your public APIs, and you need a full set of modern API management functions, you can choose to either upgrade Layer7 or add Apigee on-top.
Api management team
Another reason could be "separation of concerns" combined with "Conway's law". One department (or set of product teams) can deliver the APIs, the other teams can manage them. API management requires all kind of governance tooling an processes. If it is a small team that does the API management for your company (e.g. create the proxies, give support to external developers, maintain the developer portal) Apigee might be a fast and less complex alternative to Layer 7.
Connectivity
If the Layer7 platform has no external internet connectivity yet, the addition of a separate API management platform might be the fastest choice in an enterprise environment. You could to go for a separate Layer7 setup (separation of concerns) with the latest version (or go SaaS). This can leverage the Layer7 knowledge in your company. If the API management team has no Layer7 knowledge, Apigee could be a better choice because of its simplicity (Conway's Law).
Related
Our company is considering Neo4j for a database solution. We're using to Oracle dbs, and have relied upon their built in user authentication management to control who can connect to the db, who has read or write access, and what they are allowed to view in the db.
With Neo4j, most of these security options are missing. While we don't necessarily need to control visibility of nodes and relationships on a per-user level, the lack of multiple user accounts and the inability to control read/write access per account could be a dealbreaker. While application access of Neo4j should be well-contained and secure, we want to allow read-only accounts via the browser client to our developers (at least in our dev and qa environments).
The only solution that's jumped out at us so far has been GraphAware's Enterprise Security offering. I'd like to know if there are any other solutions out there that are compatible with Neo4j 3.0. At the moment we are not considering using the Neo4j REST API.
GraphAware Enterprise Security is compatible with 3.0 and there are no other solutions as far as we are aware. That said, judging from Github activity, it looks to me like the security mechanisms in Neo4j 3.1 will be enhanced to include multiple users and LDAP integration. We have to wait for 3.1 to be out. GraphAware Enterprise will be compatible with Neo4j 3.1 and use its native security features where possible.
DISCLAIMER: I work at GraphAware.
I did find one other partial solution to this, though it has its own hoops to go through to set up.
With the Enterprise edition, in a clustered environment, a node can be configured to be a read-only slave, and configured with its own login/pass for dev use.
We're planning to develop a web based Healthcare Practice Management System. Due to HIPAA we're requested to deploy the app in our own premises. Our company is relatively small currently we have only software engineers and no devops engineers but still we want to develop the application to support horizontal scaling(adding more servers).
Planned to use:
Python3 (Django)
PostgreSQL
I'm looking for something like AppScale but with the freedom of choosing our own runtime, database and frameworks.
In other words from the software engineer's perspective:
Should provide an easy way to deploy django application
Should have web based dashboard to monitor and control(like AppScale)
Should make load balancing simple (app and database)
AppScale implements the Google App Engine APIs which, IMHO, make it super easy to develop web apps quickly and efficiently.
On top of that, you get auto-scaling, load balancing, and the ability to deploy on-premises and plug in any third-party library you need.
AppScale already comes with a dashboard and will soon be launching a new management service for your AppScale deployment(s).
If you're not particularly hung up on Python3 and PostgreSQL, all of the above seem to cover your requirements.
It's worth noting that opting for the GAE model means you opt for NoSQL and, so, postgres is probably not the best option.
Disclaimer: I'm part of the AppScale team and we're already helping companies develop and deliver their apps in the HIPAA compliance realm.
I chose Kubernetes which is a container orchestration technology specifically designed for Docker and also found that scaling is not just the responsibility of platform that the app is deployed on but also its depends on how the app is designed and coded. For that The Twelve-Factor App methodology is really helpful.
But I can't deploy database on Kubernetes because its not recommended by Kelsey Hightower(author of Kubernetes Up and Running) in his talk. So, for now I chose to deploy my database on a VM.
I'd like to create a simple server service that can perform the following tasks:
Retrieve presence info for specified user(s).
Send message to specified user.
From what i've been reading, and because i'm siting server side I could choose to use UCMA 5.0? But i'm seeing a lot of push of the new UCWA SDK and working with the UCWA rest services. Is there any particular reason why i would use UCWA server side rather than just the UCMA API? I read that UCWA will, in the future, be support by Microsoft for Cloud --- Any input and experiences shared on this would be great.
Thanks, mike
UCWA will be at some point be supported in Office 365 indeed. So if you create an application with UCWA you can expect it will run in the next future on your S4B On-Prem as well as on Office 365.
I have to say anyway this support for UCWA on 365 is already long awaited, and still there's no official announcement about availability date.
A very good reason to choose UCWA instead of UCMA, also in case of server automation, is the much simpler deployment of UCWA (UCMA deployment is quite tough).
UCMA must run on a Windows Server OS which joins the S4B farm basically (thus sits in your DMZ)
UCWA can run on any device that 'speaks' HTTP. Your UCWA App can run, for instance, on a Raspberry Pi
I think this is a huge difference, for sure it is for your system administrator
Old thread, but in my experience, writing server-side code with UCMA is somewhat easier than trying to use UCWA - and all that UCWA really is is a UCMA application sitting on your Lync/S4B server with a REST wrapper.
For the fairly simple use-case you've described, you could write the service as a client-endpoint UCMA application, which avoids the rather irritating Lync/S4B topology changes and deployment headaches that Massimo alludes to for a TrustedApplication. In this configuration, you are essentially just a third-party client, and you provide the credentials to sign into Lync/S4B as a specified user. Under this scenario, the only requirements are that the server running your application needs to be joined to your domain, run a 64-bit Windows OS, and have the UCMA runtime installed.
Some sort of API support for Skype for Business on Office365 is badly needed. There was some promises of a UCMA-like SDK for Office 365, but it has been more than six months with no hints of an actual release.
Can we build commercial apps using the IBM Worklight free Developer Edition?
I searched the IBM official site and I sensed that we have to buy the license to develop commercial apps. But, can someone please clarify it?
Legally speaking: No, you cannot.
Non-Production Limitation
The Program can only be deployed as part of the Licensee's internal
development and test environment for internal non-production
activities, including but not limited to testing, performance tuning,
fault diagnosis, internal benchmarking, staging, quality assurance
activity and/or developing internally used additions or extensions to
the Program using published application programming interfaces.
Licensee is not authorized to use any part of the Program for any
other purposes without acquiring the appropriate production
entitlements.
Technically speaking: you could create an application that does not utilize Worklight features that in order to use them in a production environment, you'd have to buy the Consumer or Enterprise Edition of IBM Worklight.
By doing so you will lose:
The ability to install Worklight Server on an application server
The ability to utilize Worklight Adapters for backend connectivity, that rely on Worklight Server
The ability to secure your application using numerous built-in security features (application authenticity, device provisioning, ...)
The ability to manage your applications (notify, disable, ...)
The ability to remotely update (Direct Update) your applications
The ability to leverage Worklight's unified Push Notifications
The ability to see operational analytics
... and the list goes on.
Instead, you will have to rely on AJAX requests and spend time on (re-)implementing various aspects required for an application (but that's also of course depending on the scope and purpose of the application).
Also see:
https://stackoverflow.com/questions/17030963/ibm-worklight-license-is-worklight-free-to-use/17031953#17031953
IBM Worklight - Limitations of Worklight Studio for Developers
For any inquiries about Worklight I would suggest to contact IBM:
https://www14.software.ibm.com/webapp/iwm/web/signup.do?source=raq&S_TACT=109HE02W&lang=en_US
We've discussed SSO before. I would like to re-enhance the conversation with defined requirements, taking into consideration recent new developments.
In the past week I've been doing market research looking for answers to the following key issues:
The project should should be:
Requirements
SSO solution for web applications.
Integrates into existing developed products.
has Policy based password security (Length, Complexity, Duration and co)
Security Policy can be managed using a web interface.
Customizable user interface (the password prompt and co. screens).
Highly available (99.9%)
Scalable.
Runs on Red Hat Linux.
Nice to have
Contains user Groups & Roles.
Written in Java.
Free Software (open source) solution.
None of the solutions came up so far are "killer choice" which leads me to think I will be tooling several projects (OWASP, AcegiSecurity + X??) hence this discussion.
We are ISV delivering front-end & backend application suite. The frontend is broken into several modules which should act as autonomous unit, from client point of view he uses the "application" - which leads to this discussion regrading SSO.
I would appreciate people sharing their experience & ideas regarding the appropriete solutions.
Some solutions are interesting
CAS
Sun OpenSSO Enterprise
JBoss Identity IDM
JOSSO
Tivoli Access Manager for Enterprise Single Sign-On
Or more generally speaking this list
Thank you,
Maxim.
What about FreeIPA?
"FreeIPA is an integrated security information management solution combining Linux (Fedora), 389 (formerly known as Fedora Directory Server), MIT Kerberos, NTP, DNS. It consists of a web interface and command-line administration tools."
If you focus on web applications, check out http://oauth.net/.
CAS has strong adoption, user-base, and a strong lead (who recently switched jobs, but is still comitted to the project). It is straightforward to integrate (if you're comfortable writing Java code/configuring Spring beans), and can do all your requirements, noteably:
SSO solution for web applications.
YES
Integrates into existing developed products.
YES (though some cleaner than others - but many modules are available for major products, and it supports common standards (SAML, OpenID).
has Policy based password security (Length, Complexity, Duration and co)
*YES - can easily be implemented, and some extensions to integrate with LDAP (probably the most common user store) are supported
Security Policy can be managed using a web interface.
NO - though one could be build fairly simply - if you're comfortable with development, and given that this is likely to be a non-trivial project, I'd recommend considering this a non-blocker given that the product is open-source
Customizable user interface (the password prompt and co. screens).
YES - easily customized through some basic HTML/CSS editing
Highly available (99.9%)
YES - both reliable, and can support multiple node/failover scenarios easily
Scalable.
YES - used in many high-traffic environments both intranet and internet
Runs on Red Hat Linux.
YES
Oracle Enterprise Single Sign-On is not what you're after - it requires a Windows executable to be deployed. Oracle Access Manager is closer to what you're after (though it's not free or Java-based).
The major commercial players in the Identity and Access Management (IAM) market space are CA, Oracle, IBM, Sun and Novell. None of these are free solutions but they have many of the features that you are looking for.
For free software, I recommend DACS: The Distributed Access Control System. I know that one department where I work has implemented this with great success. It doesn't have as many features the commercial IAM products but otherwise is a good solution.
I have used Tivoli Access Manager backing onto Websphere and IIS boxes - the way it writes access information into the page headers is very useful. On the downside, I didnt find the DB2 Ldap backend very scalable or reliable, and you know with IBM this isn't going to come cheap.
Also the asynchronous paths (junctions) used to identify different servers is a bit of a hack really eg http://mysite/myserver/myapp - a very bad idea and not thought through very well.