I am looking for an Opensource lightweight IAM to be used in development as a substitute for the real commercial IAM in production. Something with basic IAM functionalities, easy to install & easily configured to inject HTTP headers like user group.
Is OpenAM a good option? Any recommendations?
OpenAM comes from a very good pedigree...is forked from OpenSSO which is open-sourced code from the original SUN Access Manager product. OpenSSO was abandoned by Oracle after the Sun acquisition, so another company took it over and promoted a developer community around it.
Overall its a good choice for your requirements; that is:
Production-ready - yes, this version and previous versions have been used in production implementations
basic IAM functionality - it contains basic web access management functions and more than a few advanced features.
Inject HTTP headers - Yes, this is a standard function among web access management products.
In the past, a limitation with OpenAM/OpenSSO is that it required Sun Directory as the configuration store; however, this has changed with recent releases allowing other directories to be used.
Expect that installation and configuration of OpenAM to be rather command-line intensive; that is, with a minimal package installation and then options set in config files or thru utilities.
Hope that helps...
Related
Years back, there was a Microsoft package manager called PackageManagement (aka OneGet), which seems to be based on PowerShell command conventions, and was extensible.
Recently, Microsoft introduced another package manager tool known as winget, which is still considered pre-release. It seems not to use the PowerShell conventions.
What is the relationship between these two?
Is WinGet going to replace OneGet, or will there be some sort of interop?
There is no relationship other than both were created by Microsoft, apparently by different teams at different times.
PackageManagement (formerly OneGet, est. 2014) is a unified manager that does not have its own repository. It relies on other providers instead (for example ChocolateyGet, PowerShellGet). Since it is all PowerShell, it offers good CLI and scripting experience.
WinGet is still in preview (as of August 2021). It will be part of App Installer app distributed through Microsoft Store. WinGet has a repository of packages maintained on GitHub. The client is written as native C++ console application. All output is text-only and lacks all the nice things PowerShell gives us.
There is a third-party OneGet provider for Winget and also quite strong user voice to add official PowerShell support. See the following GitHub issues:
https://github.com/microsoft/winget-cli/issues/221
https://github.com/microsoft/winget-cli/issues/674
WinGet gets regular releases, so there is hope WinGet will improve and add official PowerShell support.
I am using ODM 8.10 and want to automate building rule app files. The code is currently configured in the old Classic Rule Project, and we are trying to avoid migrating to Decision Services at this time. I have found build jars for Decision Services but nothing so far for Classic Rule Projects. There must be a way to do this as the rule app jar files are created in the eclipse IDE when you deploy/export a ruleApp. I am trying to find out the jar files the IDE uses and the commands it calls to execute the rule app builds.
Re: "There must be a way to do this"
But you will not necessarily have access to it. The ODM product developers have experience, source code, documentation, and other tools that you do not have access to.
Having said that, there is an build/deploy API that you may be able to access via ANT. I haven't used it since switching to Decision Services when that became feasible in ODM 8.7. Standard practice before that time was to automate deployments via Ant and a "headless" version of Eclipse. If the latest online docs don't describe it, you might try the older docs.
WARNING: Classic Rule Projects are a dead end! Not only will all your effort building them in a non-standard way be wasted, I believe that it will likely be more trouble than just migrating to Decision Services (which is not usually that difficult).
In Installing SAP Commerce Using Installer Recipes and Installer Recipe Reference, there is a comment that says something like:
The installer is currently only intended to install SAP Commerce in
development environments or for demonstration purposes. Do not use the
installer to install SAP Commerce in a production environment.
However, guides like Customizing the Accelerator with extgen and modulegen usually mention recipes:
On Windows: install.bat -r b2c_acc_plus
So, how do you really set-up a project from scratch? Do you start with recipes, or do you start with ant modulegen?
I don't see clear instructions (or best practice) on how I should build a B2C/B2B application from scratch for development and then preparing it for Production. (Maybe there is a gap in the instructions, or I just don't know where it is)
Even the Installing SAP Commerce Cloud for use with Spartacus guide mentions starting with a B2C recipe. Does this mean that the starting point of building a SAP Commerce project is to use recipes? Are there cases where you would not use a recipe, and build everything from scratch using ant modulegen and ant addoninstall?
It is not recommended to use recipe for direct installation on production. Reason being it installs a preset of hybris extensions which might or might not be needed for your requirements, also it might not be a allowed to use under the license you got.
However, when you start your development, you can use recipe to give your development a quick start. It generates the raw structure for your e-commerce application which you would need to customize and later deploy on your production.
how do you really set-up a project from scratch? Do you start with recipes, or do you start with ant modulegen?
Well, You can use any of those. If you are looking for difference, it has already been answered here
how I should build a B2C/B2B application from scratch and prepare for production?
For production hybris deployment procedure refer this.
NOTE :
a) recipe installation does more than what you can achieve using modulegen like complete installation, configuration and initialization for a running e-commerce example. I think once you go through above links, you will have a much better understanding on this.
b) When you go with recipe, it will install related extensions which you might not want to use or don't have production license for that. Please be considerate to review and disable such extensions,
Thanks
A few more points adding to the answer by www.hybriscx.com
Generally, the integrations in a recipe are mock integration e.g. payment integration as the purpose of a recipe is to provide a ready-to-use demo/reference application (store).
The data (catalog, users & password, usergroups, roles, promotions etc.) in a recipe are sample data. The same goes with the look-n-feel (logos, colour, layout etc.). Every business requires its specific data and look-n-feel.
The system configurations/properties (e.g. memory configuration, logging configuration etc.) may be optimised for the demo purpose but the production setup may require a different configuration. On the same line, configurations like hosts, ports, encryption etc. are general purpose configurations and a production environment may need to change them.
The database set up by a recipe is generally HSQLDB which is only good for development/demo.
I'm looking at doing some Expression Engine development, but it looks like with Expression Engine 2.x there is no longer the free Core version to download. This is for a single client as I don't normally do EE work.
Am I allowed to download their files/db to my local machine for development or will that be breaking any sort of license? Or am I expected to purchase a license even though I won't be running an EE site myself? The client has a full EE license, but I don't know that I want to drop $99 to build a basic module for a client.
An ExpressionEngine license purchase allows a single “live” installation in a production environment and ancillary “development use only” installations as needed to support the live installation (such as development and a staging servers).
ref: http://expressionengine.com/user_guide/license.html
So, yes if you download the clients files/DB and install locally to continue the build or test with it, that's completely fine and within the license agreement.
In a normal ASP.NET Website there is a Web Deployment Project that we can use to pre-compile our entire website and then we can safely upload this project to our production server in order to protect our code.
What can we do for ASP.NET MVC 2?
Link to it as is available today (RTM version)
Visual Studio® 2010 Web Deployment Projects - RTW
Make sure you install the latest security patches for your operating system and hire a good network administrator. No kidding. No matter what you do if a hacker gains control over the server he will get the code under one form or another even if it is precompiled. This being said it is a good idea to precompile the application and deploy only the assemblies instead of the source code. You could also consider obfuscating it also but this is something usually done for client applications which you deploy to your users computers and less frequently done in server side applications because you control the server.