I am using hadoop-2.6.0 secured with kerberos authentication. For http authentication there is a property called hadoop.http.authentication.signature.secret.file
I have set this property as below in core-site.xml
<property>
<name>hadoop.http.authentication.signature.secret.file</name>
<value>C:\http-signature.secret</value>
</property>
and the http-signature.secret file is empty. But http authentication working fine. If i disable this property then i am getting error while starting nodes.
I want to know the usage of this secret file. Why should we set this property? I have googled it but couldn't find the reason.
Help me to understand the usage of this file.
I found the answer in the below link
http://hadoop.apache.org/docs/stable1/HttpAuthentication.html
Related
When I add a data source that contain the user and password properties in the server.xml in WebSphere Liberty
Example:
<dataSource jdbcDriverRef="db2-driver" type="javax.sql.DataSource">
<properties.db2.jcc user="MyUser" password="MyPassword"
databaseName="dbName" serverName="localhost" portNumber="50000"/>
</dataSource>
I get the following warning in the logs:
J2CA8050I: An authentication alias should be used instead of defining a user name
and password on dataSource[default-0].
Looking at how to do this in Configuring authentication aliases for the Liberty profile I see them put the user and password in another element called authData like this:
<authData id="auth1" user="MyUser" password="MyPassword"/>
I don't get what advantage moving the user name and password from the dataSource element to the authData element is giving me. In both cases the password is showing in plain text in the server.xml file.
WebSphere Liberty uses an adapter to manage it's database connections. By specifying an authentication alias the password used by the adapter will be encrypted. If you do not use an auth alias, the userID and password will get stored without encryption on adapter properties.
Additionally, aliases provide another layer of abstraction since the aliases themselves are a resource. The benefit here is that the alias can be configured independently if the database user/password needs to be changed and there are many datasources configured, they can all point to the same auth data.
Use the securityUtility encode command in the wlp/bin directory to encode the password in your server.xml.
If you add authentication data via WebSphere Developer Tools (WDT), you will be prompted during setting password to encode (xor) /encrypt (aes) it. And it will be saved in server.xml for example like that:
<authData user="user" password="{xor}Lz4sLCgwLTs="></authData>
I have an API that works no problem providing the "Make this the default version" checkbox isnt checked, once checked I get this error back
<ams:fault
xmlns:ams="http://wso2.org/apimanager/security">
<ams:code>900906</ams:code>
<ams:message>No matching resource found in the API for the given request</ams:message>
<ams:description>Access failure for API: xxxx/xxxx, version: v0.1 with key: xxxxxx</ams:description>
</ams:fault>
Is there something I have missed at all?
Thanks,
Ash.
EDIT - Extra Detail and Logs
TID[-1234] [AM] [2014-07-10 13:05:56,238] ERROR
{org.wso2.carbon.apimgt.gateway.handlers.security.APIAuthenticationHandler}
- API authentication failure org.wso2.carbon.apimgt.gateway.handlers.security.oauth.OAuthAuthenticator.authenticate(OAuthAuthenticator.java:157)
org.wso2.carbon.apimgt.gateway.handlers.security.APIAuthenticationHandler.handleRequest(APIAuthenticationHandler.java:92)
org.apache.synapse.rest.API.process(API.java:285)
org.apache.synapse.rest.RESTRequestHandler.dispatchToAPI(RESTRequestHandler.java:83)
org.apache.synapse.rest.RESTRequestHandler.process(RESTRequestHandler.java:64)
org.apache.synapse.core.axis2.Axis2SynapseEnvironment.injectMessage(Axis2SynapseEnvironment.java:220)
org.apache.synapse.core.axis2.SynapseMessageReceiver.receive(SynapseMessageReceiver.java:83)
org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:180)
org.apache.synapse.transport.passthru.ServerWorker.processNonEntityEnclosingRESTHandler(ServerWorker.java:344)
org.apache.synapse.transport.passthru.ServerWorker.run(ServerWorker.java:168)
org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:172)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
java.lang.Thread.run(Thread.java:744)
Please save and publish the API once you made the change to the API. This may be causing the issue.
Once you have published you should see 2 sets of production url (one with the version and one without the version). Please check if the same is available in the API store for your API.
You'll first want to turn on wire logs in that environment by editing your ../repository/conf/log4j.properties file and restarting the service. This will allow you to see the request headers for both the initial request to the gateway and the request from the gateway to itself (or other gateways in your cluster) since that's how requests to a default API version are resolved. This can help you identify whether your Authorization header values are actually making it to the authentication handler.
After you take a look at this, note that when you publish an API with a default version, you're actually creating (or updating) two separate synapse configurations for the API: a versioned configuration and an unversioned configuration. The portion of the latter's definition that you need to check is:
<else>
<header name="WSO2_AM_API_DEFAULT_VERSION" scope="transport" value="true"/>
<property name="uri.var.portnum" expression="get-property('https.nio.port')"/>
<send>
<endpoint>
<http uri-template="https://localhost:{uri.var.portnum}/myApi/v1">
<timeout>
<duration>60000</duration>
<responseAction>fault</responseAction>
</timeout>
</http>
</endpoint>
</send>
</else>
By default, the newly generated definition for the default version attempts to send the request to localhost, which may not be what you want. Check at ../repository/deployment/synapse-configs/default/api and make sure that this definition is correct.
Since it looks like this is actually an authentication error, you should also test a new subscription. Create a new application with some subscriber, subscribe to the API, and generate new access tokens. I wouldn't understand why (since setting a default version doesn't create a new API entry in the AM_API table) but this could possibly be due to the access token credentials being invalid for the default version, and generating new tokens should (in theory) test against this.
I have a question about the connectAs="endUser" option, found in the adapter XML file.
In the design mode I can read
- endUser: The connection to the back end will be created with the user's identity, as authenticated by the authentication realm
So my question is: Does it have sense to use the option connectAs="endUser" without being authenticated and without defining a security test?
I am having this question, because I used to put the connectAs="endUser" in the authentication procedure
<procedure name="authenticate" connectAs="endUser"/>
Is that wrong?
So as you can see in the documentation using connectAs="endUser" is "Only valid if a user realm has been identified in the security tests for this procedure."
Here are some resources you may want to look into:
procedure element of the adapter XML file
http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/index.jsp?topic=%2Fcom.ibm.worklight.dev.doc%2Fdevref%2Fr__procedure_.html&resultof%3D%2522%2563%256f%256e%256e%2565%2563%2574%2561%2573%2522%2520%2522%2563%256f%256e%256e%2565%2563%2574%2561%2522%2520
The authentication element of the HTTP adapter
http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/index.jsp?topic=%2Fcom.ibm.worklight.dev.doc%2Fdevref%2Fr_the__authentication__element_o.html&resultof%3D%2522%2563%256f%256e%256e%2565%2563%2574%2561%2573%2522%2520%2522%2563%256f%256e%256e%2565%2563%2574%2561%2522%2520
Can you please provide your scenario to how you would like to use this setting in greater detail
We use one of the older versions of apache axis2 for our web services framework. We are using rampart 1.2 as part of that.
Am trying to use password digest with ‘nonce’ and ‘timestamp’ mechanism for authentication. We’re getting rampart to do the verification.
I’ve got the authentication verification mechanism working fine (inc. password callbacks, etc.)
The issue I’m having concerns getting rampart to recognise a ‘replay attack’, basically the functionality of the rampart module associated with recognising these seems to be inactive.
I can send the same security header to my axis2 service any number of times (even sending a security header I generated yesterday) and it authenticates fine and completes the webservice request.
My best guess is : I’m missing a config setting somewhere for the rampart module that enables the functionality to detect replay attacks.
I’ve tried both the config suggestions given in the links below (in the services.xml file) and neither seem to work :-
http://hasini-gunasinghe.blogspot.com.au/2012_02_01_archive.html
http://axis.apache.org/axis2/c/rampart/docs/configurations.html (right at the bottom, it mentions ‘Replay attacks’)
Anyone able to help or give me some idea what I'm missing and where (I'd imagine it's config setting related) ?
I've got the module declaration for rampart in my axis2.xml file :-
<module ref="rampart"/>
And I have what I believe to be the rampart config settings in my services.xml file after all my operations are declared ;-
<parameter name="InflowSecurity">
<action>
<items>UsernameToken Timestamp</items>
<passwordCallbackClass>com.myCompany.service.dummy.MyAuthenticator</passwordCallbackClass>
</action>
</parameter>
<rampart:rampartconfig xmlns:rampart="http://ws.apache.org/rampart/policy">
<rampart:timestampprecisioninmilliseconds>true
</rampart:timestampprecisioninmilliseconds>
<rampart:timestampttl>300</rampart:timestampttl>
<rampart:timestampmaxskew>300</rampart:timestampmaxskew>
<rampart:timestampstrict>false</rampart:timestampstrict>
<rampart:ReplayDetection>1000</rampart:ReplayDetection>
</rampart:rampartconfig>
If you are using rampart-1.2 you will have to implement the replay detection in your service.
The incoming TimeStamp information is available in the Security header processing results included in the message context properties under the key "org.apache.ws.security.handler.WSHandlerConstants.RECV_RESULTS". This is a Vector, and the first item of this is a "org.apache.ws.security.handler.WSHandlerResult" instance (wsResult in the next code snippet).
Then you can obtain the timestamp information as shown below:
actionResult = WSSecurityUtil.fetchActionResult(wsResult,
WSConstants.TS);
if (actionResult != null) {
Timestamp timestamp = actionResult.getTimestamp();
//Your validation goes here...
}
As suggested by the blog post you referenced you can try upgrading to rampart-1.6.2 and using the policy based configuration.
Our requirement is to have email id as the username for the login. We used the blogger post found at this link. We built the business logic in the customauthenticator class file, and just deployed the BE authentication piece. We used the dropins folder as suggested and modified the authenitcators.xml file in the conf/advanced directory.
We tried with both disabled=true and disabled=false, and lower and higher priorities. There was simply no change. It didn't appear that the jar file was being picked up. Is there any other configuration that we are missing in order to get the custom authentication activated? Any pointers will be helpful.
You do not have to write a custom authenticator for your requirement.
If you enable JDBCUserStoreManager in user-mgt.xml and make the following property to true, then email id will be used as username.
Property name="IsEmailUserName"
Thanks,
Hasini.