is there a way to configure mTLS in Helidon MP without saving the following to disk?
server.sockets.0.tls.trust.keystore-path
server.sockets.0.tls.private-key.keystore-path
client.tls.client.keystore-path
If we have these certificates as a Java object is there a way to pass those to the Helidon server?
I am using Helidon MP 2.3.1
I have tried configuring it with certificates on disk but I would like to avoid that.
From David Kral, there is no "easy" way to do this. Basically there are two possible options for you.
It is possible to create a new config with runtime created ConfigSource and instead of setting resource.resource-path one could use resource.content . The value here is Base64 encoded resource value. That means, you can store obtained certificate there.
Alternatively, you could create your own CDI extension. Inject ServerCdiExtension there and create initialization method (Similar to how ServerCdiExtension#startServer method looks like in terms of parameters). In this method you can obtain WebServer.Builder from injected ServerCdiExtension instance and it is possible to set Tls configuration the way you want it to be set. It is important to note, this extension has to have higher priority over theServerCdiExtension .
Related
Helidon uses annotations like
#RoleValidator.Roles({“my_admins”, “test”})
to do the authorization.
I am wondering if there is a way to do authorization differently using configuration settings for paths, for example.
Basically, the question is.
Is there a way to use configuration instead of annotation to authorize requests to particular endpoints?
If yes, would it be possible to get the SecurityContext like in a case of annotation?
Example with multiple roles for one endpoint would be helpful
I am successfully using annotations but in some cases it is not convenient
You should be able to do what you want using configuration instead of annotations. It would look similar to what our documentation describes here: https://helidon.io/docs/latest/index.html#/se/guides/security-oidc#Restrict-access-to-a-specific-role
You might not even use the annotations given your use case.
You would define the user-to-roles mapping however makes sense for you (Helidon config would work as would some other provider) and then use Helidon config to set up each endpoint's roles-allowed setting as needed.
As you are using Helidon MP, you could for example add something like this to your META-INF/microprofile-config.properties file:
web-server.paths.0.path=/greet
web-server.paths.0.methods=get
web-server.paths.0.roles-allowed=admin,dev
web-server.paths.0.authenticate=true
(These particular settings are drawn from Helidon's MP QuickStart example but you get the idea.)
I am new in apache camel. I want to do a GET REST call to get data and then I want to mapping these data to my Java bean. How can I do that with camel? I want to do it in a spring MVC web application.
I know how to do it with RestTemplate for example, but I want to use apache camel.
I've checked this documentation http://camel.apache.org/cxfrs.html but still I don't know how to set up for accomplishing this.
Please if you can provide some examples will be great.
There are a few different options. I'll walk through one...
First, define your rest configuration with bindingMode=auto
restConfiguration()
.component("jetty").host("0.0.0.0").port(9000)
.bindingMode(RestBindingMode.auto);
Next, when you define your particular rest service, specify a type (this is the type of the incoming body:
rest("/")
.put("/A/{subpath1}/{subpath2}")
.type(MyPojo.class)
.to("direct:XYZ");
That's it! The unmarshalling will be magical ;)
Alternatively, you can unmarshal things yourself.
If you'd like to see a working example of the above, check out this program: it has a main() to test it. https://github.com/DariusX/CamelSandbox/blob/master/CamelSandbox/src/main/java/com/zerses/camelsandbox/rest/RestConsumerBindingTest.java
I have a WCF service application (actually, it uses WCF Web API preview 5) that intercepts each request and extracts several header values passed from the client. The idea is that the 'interceptor' will extract these values and setup a ClientContext object that is then globally available within the application for the duration of the request. The server is stateless, so the context is per-call.
My problem is that the application uses IoC (Unity) for dependency injection so there is no use of singleton's, etc. Any class that needs to use the context receives it via DI.
So, how do I 'dynamically' create a new context object for each request and make sure that it is used by the container for the duration of that request? I also need to be sure that it is completely thread-safe in that each request is truly using the correct instance.
UPDATE
So I realize as I look into the suggestions below that part of my problem is encapsulation. The idea is that the interface used for the context (IClientContext) contains only read-only properties so that the rest of the application code doesn't have the ability to make changes. (And in a team development environment, if the code allows it, someone will inevitably do it.)
As a result, in my message handler that intercepts the request, I can get an instance of the type implementing the interface from the container but I can't make use of it. I still want to only expose a read-only interface to all other code but need a way to set the property values. Any ideas?
I'm considering implementing two interfaces, one that provides read-only access and one that allows me to initialize the instance. Or casting the resolved object to a type that allows me to set the values. Unfortunately, this isn't fool-proof either but unless someone has a better idea, it might be the best I can do.
Read Andrew Oakley's Blog on WCF specific lifetime managers. He creates a UnityOperationContextLifetimeManager:
we came up with the idea to build a Unity lifetime manager tied to
WCF's OperationContext. That way, our container objects would live
only for the lifetime of the request...
Configure your context class with that lifetime manager and then just resolve it. It should give you an "operation singleton".
Sounds like you need a Unity LifetimeManager. See this SO question or this MSDN article.
If I have a web serice and a client consuming tis webservice, and then I change the service location, orI add another parameter, what is the usual way to change the client?
Do you necesarily need to update the client/ Was UDDI helping in this kind of situation?
You should definitely read Service Versioning - it has the information you need.
But the answer to your question is: maybe.
There are two types of changes: breaking and non-breaking. Unfortunately, sometimes it's not obvious what is a breaking or non-breaking change since it could depend on what the client is doing (and you may not have knowledge of how your service is being used).
In terms of changing the service location this is usually a breaking change. However, as you mention, if the client is using UDDI then they should be able to retrieve the new endpoint location and that change would not be a breaking change.
If you add another parameter then that might be a breaking change (or it might not). If the parameter is optional and the client is using lax versioning (e.g. WCF, .asmx) then the change should not be a breaking one. But it might be that the client is expecting a very specific format or they are doing some schema validation etc. and the optional parameter might cause a failure.
It depends on the nature of change you apply in the service definition. If you add something optional that only new clients can consume but the old clients can ommit, you have introduced a backward compatible change so the clients shouldn't be updated unless they decide to use this new feature. Any change that affects the way the existing clients use the service will require a client update as it represents a breaking change.
In the case of WCF, if you use the latest version 4.0, it introduces a new protocol implementation WS-Discovery, which can help clients to find the service url and the right version they can use. Using this approach, you can for instance, deploy a new version in a different url and the client applications can discover it automatically.
Regards
Pablo.
Hey without fully understanding your problem, and from what i can get from your questino it sounds like you need to update your web reference on the client.
If you have updated your references, not changed the location:
So Load up your client solution, then find your References (not dll references) but Web/Service References, and then right-click and select "update web references"
If you have changed the location, you can change the endpoint if you go to properties, but I would just delete the existing one and create a new one using the new location.
Hope it helps.
For more info check out http://msdn.microsoft.com/en-us/library/bb628652.aspx
I am new to SOAP and Axis 2 framework. I started with writing simple program for returning String, int to the client side. Now I want to have program on the server which return java Object like Vector, List and Properties to the client side.
But while writing the client side program, I am not able to do that. Please do give some example too in order to understand it easily.
All the released versions of Axis2 does not support List, maps and Vector. So you won't be able to use them. Only solution is to use arrays. Those features are now added to the trunk and will be available for 1.7.0.
Der are many ways to do it. You can return objects in the form of JSON, or use JAXB to convert objects into XML and send it. Or u can send plain java objects(But it is not acceptable since they will be soap objects and sometimes may not be receivable by clientside of different platforms). Start with some tutorials for JAXB or Jersey if you want to use Restful architure.