Github Link
Missing username and password properties from the solr connector configuration to authenticate with the solr.
Is that possible to authenticate with solr via connector config?
How to pass username n password within the connector config?
Looks like solr.username and solr.password aren't actually used in the connector. The SolrClient is created with a default HttpSolrClient without any credentials in this source file in Github. But MatsLindh's point about embedding username and password in the URL is a good one and I'd have expected it to work.
There's a relevant thread here:
Solr6.3.0 SolrJ API for Basic Authentication
I haven't vetted the last answer in the thread, which doesn't really address the original topic in that post, but it is a concise example of creating a SolrClient with authentication. The SolrClient needs to wrap an underlying HttpClient that provides the basic auth, and the Kafka Solr sink connector isn't doing that.
Related
I am working on a project and I am forced to not using Spring Boot. I have a Eureka server running on localhost:8090 and some services already registered on it.
How can I force Apache Camel's serviceCall to look for services on the Eureka server?
I know that to make it work for Consul as the service discovery you should do something like following:
ConsulConfiguration config = new ConsulConfiguration();
config.setUrl("http://ip:port");
ConsulServiceDiscovery discovery = new ConsulServiceDiscovery(config);
// configure camel service call
ServiceCallConfigurationDefinition config = new ServiceCallConfigurationDefinition();
//config.setServiceDiscovery(servers);
// register configuration
camelContext.setServiceCallConfiguration(config);
How to make it work for Eureka server on localhost:8090??
there’s no direct support for eureka in camel so if you can’t use spring-boot, you need to build your own ServiceDiscovery implementation
As #Luca suggested and after some research I came to this conclusion that you should implement a custom service discovery to read from Eureka. In order to do that I did the following:
Extending my EurekaServiceDiscovery class from DefaultServiceDiscovery class of camel-core module
Overriding the method public List getServices(String name) of
DefaultServiceDiscovery class which is responsible to retrieve services from Eureka
Using Eureka REST API to get all the services in the overrided method. In order to do this you should convert the recieved JSON data from Eureka REST API to appropriate java classes. You need to define Application and InstanceInfo classes based on those JSON data.
For example after running Eureka on localhost:8090 and after registering a service named account-service on it, you can git information of account-service by sending a Http.GET request to localhost:8090/eureka/apps/account-service
For more info look at this Github repo: https://github.com/hamedmirzaei/service-gateway-bootless
Http Form adapter serves as an authentication service in my application. I have not implemented any application on the Identity Provider to get user inputs.
Therefore, on successful authentication, SP verifies the user's signature and redirects to the application. At my target Resource, I receive an open token. Is it still possible to utilize the open Token Jar to read the user attributes from OTK?
**Note: ** In Service Provider, I use open token Adapter.
Also, please let me know if there is any other possible way of getting the user attributes other than using the open token adapter/http form adapter.
Thanks.
There are numerous SP Adapters you can choose to use for your last mile integration with your application. The OpenToken Adapter is just one of them. If your application is in Java and you are using the SP OpenToken Adapter, then you would most likely use the Java OpenToken Agent implementation within your application to read the OTK (documented in the Java Integration Kit). If you look at the Add Ons list, there are actually 3 flavors of OTK Agents (.NET, Java and PHP from PingID. Ruby on Rails and Perl are available via respective Open Source repositories).
However, you are not limited to OpenToken Adapters. The Agentless Integration Kit is also very popular for SP/last-mile integration with PingFederate.
Unfortunately, the question is just too open ended for the Stackoverflow format. I would suggest talking to your Ping Identity Solution Architect who can help steer you in the right direction and ask the necessary follow-up questions on your use case.
If understand the question correctly, you desire attributes to be fulfilled that the web application can read and utilize. This starts with the SP Connection configuration. I am going to assume you are using Active Directory and already configured that data source along with the Password Credential Validator (PCV) for the HTML Form IdP Adapter. In the SP Connection you will need to extend the attribute contract to define the values to put into the SAML assertion and then use the Active Directory data source to fulfill the attributes. When the SAML assertion is received by the PingFederate SP role server, the SP Adapter maps the attribute values from the SAML assertion into the OpenToken. When your application receives the OpenToken, it can read the values.
I'm new to Solr. I'm implementing auto complete functionality for my application. I have configured the required fields in solr and created a custom request handler /suggest. I'm finding it tricky to access it via solr java client solrj. I'm even fine with the spring data for solr. Please somebody help to access my custom request handler from solr java client.
With spring-data-solr you might add #Query(requestHandler = "/suggest") or use query.setRequestHandler("/suggest").
In case you're doing autocomplete you might also give /terms and the SimpleTermsQuery a try.
SolrJ supports this through the use of the setRequestHandler method on the SolrQuery class.
I'm trying to connect with Solr Server from a SolrJ client, but it gives an HTTPResponse Exception.
Here's my code:
SolrServer server = new HttpSolrServer("http://"localhost":8983/solr/");
Here's the exception:
java.lang.NoClassDefFoundError: org/apache/http/NoHttpResponseException:
Does Solr have a default address? Where can you find it?
I am not familiar with SolrJ - but the endpoint seems to be missing the core name to me.
You would need to point your Solr client to a particular core.
The URI for the core would look like this (for reloading core command)
http://localhost:8983/solr/{{solrCoreName}}
The admin UI should be accessible at
http://localhost:8983/solr
By default, Solr will start on port 8983. That can be changed though. You can change that for example in the solr.in.sh file using the SOLR_PORT property.
I would like to configure Tomcat to be able to connect to AD and authenticate users accordingly.
In addition, I would also like to invoke some web services (in this case, Share Point) using the client credentials.
So far, I've managed to successfully configure Tomcat to use SPNEGO authentication, as described in the tutorial at http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html. Note that I have used Tomcat's SPNEGO authentication (not Source Forge's or Waffle).
I did not use Source Forge's implementation since I wanted to keep things simple and use Tomcat's as provided out of the box. In addition, I wanted all the authentication and authorization to be handled by Tomcat, using the SPNEGO as the authentication method in WEB.XML and Tomcat's JNDI realm for authorization.
Also I have not used WAFFLE, since this is Windows only.
I'm using CXF as my Web Service stack. According to the CXF documentation at http://cxf.apache.org/docs/client-http-transport-including-ssl-support.html#ClientHTTPTransport%28includingSSLsupport%29-SpnegoAuthentication%28Kerberos%29, all you need to do to authenticate with the a web service (in my case, Share Point) is to use:
<conduit name="{http://example.com/}HelloWorldServicePort.http-conduit"
xmlns="http://cxf.apache.org/transports/http/configuration">
<authorization>
<AuthorizationType>Negotiate</AuthorizationType>
<Authorization>CXFClient</Authorization>
</authorization>
</conduit>
and configure CXFClient in jaas.conf (in my case, where Tomcat's server JAAS configuration is located, such that my jass.conf looks like:
CXFClient {
com.sun.security.auth.module.Krb5LoginModule required client=true useTicketCache=true debug=true;
};
com.sun.security.jgss.krb5.initiate {
com.sun.security.auth.module.Krb5LoginModule required
doNotPrompt=true
principal="HTTP/tomcatsrv.corporate.intra#CORPORATE.INTRA"
useKeyTab=true
keyTab="C:/Program Files/Apache/apache-tomcat-7.0.27/conf/tomcatsrv.keytab"
storeKey=true
debug=true;
};
com.sun.security.jgss.krb5.accept {
com.sun.security.auth.module.Krb5LoginModule required
doNotPrompt=true
principal="HTTP/tomcatsrv.corporate.intra#CORPORATE.INTRA"
useKeyTab=true
keyTab="C:/Program Files/Apache/apache-tomcat-7.0.27/conf/tomcatsrv.keytab"
storeKey=true
debug=true;
};
Yet, when I'm invoking the web service, it is invoked under the service username (i.e. Tomcat's username configured in AD and in tomcatsrv.keytab), rather than the client's username (e.g. duncan.attard).
So my question is this: Is there some way in which the client's username can be delegated (or use some sort of impersonation) to CXF so that when I invoke Share Point's web service (e.g. I want to upload a file using Copy.asmx), the file is uploaded as duncan.attard and not as tomcat.srv.
Thanks all, your help is much appreciated.
Technically, this works perfectly. Here's the recipe:
You do not need a login module name if you work with credential delegation.
You have to make sure that the user account is eligible for delegation.
Take a look at the implementation of Tomcat's GenericPrincipal, it will save you the GSS credential if there is one. Cast request.getPrincipal to GenericPrincipal and get the credential.
Now say you have the credential:
Construct a Subject with the Principal and the GSSCredential as private credential.
Wrap the CXF code into a PrivilegedAction.
Pass the constructed subject and an instance of your privileged action to the Subject.doAs method and the system will construct an AccessControlContext on behalf of the passed subject and will invoke everything in JAAS on behalf of that context. CXF should use those if it is implemented correctly. This is like su or sudo on Unix.
The easiest way to test that is to create an InitialDirContext in the privileged action on behalf of the client to your Active Directory. This is how I test a working credential delegation environment.