I have a use case where I would like to integrate hdfs with my application. User management is handeled by the application. Now on HDFS side to fetch groups of a user we can use any of the predined ways defined here.
https://hadoop.apache.org/docs/r2.8.0/hadoop-project-dist/hadoop-common/GroupsMapping.html#Composite_Groups_Mapping
But in my case since my application handles users and groups is there a way to create a custom GroupMapping which talks to my application to get user and group details ?
This component of Hadoop is entirely extensible. You simply need to write a custom implementation of the GroupMappingServiceProvider, which has just 3 methods - one to translate a user to a list of groups that user is in, and two for managing the caching of the mapping. All you need to do after implementing this interface is place a JAR with your custom implementation onto the classpath of your HDFS JVMs and then specify it in the hadoop.security.group.mapping configuration.
Related
As said in the title, is there a way to add application users in Thorntail WilFly server, much like you would do with "add-user.sh -a" script in the full server distribution?
I understand you can provide an external configuration file to Thorntail but that seems a bit of overhead just for specifying where users are located.
Thanks
The answer by Thomas Herzog is very good from a conceptual point of view -- I'd especially agree with securing the application using an external Keycloak, potentially with the help of MicroProfile JWT. I'm just gonna provide a few points in case you decide not to.
You can define users directly in project-defaults.yml, like this:
thorntail:
management:
security-realms:
ApplicationRealm:
in-memory-authentication:
users:
bob:
password: tacos!
in-memory-authorization:
users:
bob:
roles:
- admin
The project-defaults.yml file doesn't have to be external to the app, you can build it directly into it. Typically, in your source code, the file will be located in src/main/resources, and after building, it will be embedded inside the -thorntail.jar. It can be external, of course, and if this is something else than a throwaway prototype or test, sensitive data like this should be external.
You can also use the .properties files from WildFly:
thorntail:
management:
security-realms:
ApplicationRealm:
properties-authentication:
path: .../path/to/application-users.properties
properties-authorization:
path: .../path/to/application-roles.properties
It depends on for what you need the users? Thorntail creates standalone Microservices, which are different to hosted applications in a wildfly-server.
Is there are a management console in thorntail?
Yes there is, but I have never used it.
https://docs.thorntail.io/2.2.0.Final/#_management
https://docs.thorntail.io/2.2.0.Final/#_management_console
The users you maybe able to create there shouldn't be persistent, because there is no wildfly-server installation as you are used to with a standalone wildfly-server installation, it is all packaged in the jar. A Microservice shouldn't need to be configured after its deployment anymore, at least not like this.
How to secure my application?
I would recommend to use an external user management via keycloak, which is integrated in thorntail via the keycloak fraction. With the keycloak fraction you can define security constraints to your endpoints similar in a web.xml.
https://docs.thorntail.io/2.2.0.Final/#_keycloak
Another way is to use the security fraction which provides you JAAS support for your microservice.
https://docs.thorntail.io/2.2.0.Final/#_security
The configuration is done via the thorntail specific project-defaults.yml configuration file, where you can configure the fractions via YAML.
What is a thorntail fraction?
A thorntail fraction is similar to a spring boot start dependency with spring, whereby the fraction provides the API for the developement and bundles the implementation and integration into thorntail. The fraction actually is a jboss module which is packaged into the standalone Microservice during re-packaging phase.
Where can I find examples?
See the following links for examples how to use security in thorntail. You should take a look at them.
https://github.com/thorntail/thorntail-examples/tree/master/security
Take a look at the src/main/resources/projects-defaults.yml which contains the configuration for thorntail fractions and the pom.xml which defines the used fractions.
I'm looking to create an Error Handling Flow, and need to capture the name of the failing processor on particular points only. An Update Attribute would be last resort as it would clutter up the templates. Ideally I'm looking for a script or similar, but I'm open to suggestions from NiFi experts.
You can use the Data Provenance feature for this via manual inspection or REST API, but by design ("Flow Based Programming"), components in Apache NiFi are black boxes independent and unaware of their predecessors and successors.
If you need a programmatic capability to access the error messages, look at SiteToSiteBulletinReportingTask. With this component, you can send the bulletins back to the same (or a different) NiFi instance via Site-to-Site and ingest and process them as any other arbitrary data.
I would like to know if there is any API in "vespa platform" which I can use to create a search definition (sd) in runtime.
This is a requirement, because the documents that I will index are depending on the user input in my front end application.
No, there is no such API available. The idea of deploying an immutable application package (including the SD) is a conscious design choice to ensure appropriate management of multiple search clusters in multiple locations over time as well as enabling source control management.
If needed, one could build what you describe "on top" of Vespa: A web service that will let you mutate an existing SD and, upon submit, create the updated application package and deploy to your Vespa cluster. Vespa will (in most cases) handle schema changes without impacting serving.
There're a lot of parameters which I need to maintain while I perform developing/debugging in my JSF/EJB application:
scheduler running or not
can emails be sent or not
can sms be sent or not
WebFilter turned on or off, etc..
What is the best practice to maintain all these parameters? Make Java properties file as described here Java Properties file examples or there's better approach?
I need to define these parameters in a single place, and get access to them from JSF and EJB projects as well.
Thank you in advance.
There are a lot of things you need to consider before you can choose the best alternative.
A properties file would be a good practice if these parameters are very rarely changed and are also user independent.
You could also implement a singleton EJB that caches these values.
If these parameters you mention are user dependent or change often it would be better if you include them as user properties, or role properties. (Following an RBAC approach)
I have an interface of global variables like so:
public interface ClientSettings{
DateTime CurrentClientTime;
string ClientImageFolder;
}
The concrete class is persisted using settings files or a database table.
These values must be accessed by entities and services, both in the domain and the application layer. I have been using DI in my application layer, so access this from there is no problem.
But now that I need to access this interface from the entities I'm not sure of the best way to do so. I don't really want to inject this into my entities. Is the service locator pattern appropriate here? Or do I have another option all together?
In this type of situation I would try to design the entities and the application layer such that the application layer provides all required settings information to the entities when operating upon them. Settings are normally an application concern and should therefore be managed by the application layer. Furthermore, an application level settings container object, such as ClientSettings may contain settings for various parts of the application which may not be applicable for a given entity. This is another argument for relieving the domain entities of the responsibility.