worklight http adapter and NTLM authentication - authentication

i'm trying to implement NTLM authentication in a Worklight HTTP Adapter in order to connect to M$ back-end servers, such as Sharepoint Web services.
i've set-up my adapter.xml file with <ntlm>.
The adapter.xml structure first version was:
<authentication>
<ntlm />
<serverIdentity>
<username>user</username>
<password>password</password>
</serverIdentity>
</authentication>
My tests are done locally with Worklight studio, i get the following issues:
1) error when invocating WL procedure:
Procedure invocation failed:Could not resolve placeholder 'local.hostname'
where do i have to put this 'local.hostname' setting?
2) i tried to specifiy the hostname property of ntlm tag as given in documentation (IBM infocenter), WL Studio says that the xml is bad formed.
<authentication>
<ntlm hostname="myComputer.intranet.com"/>
<serverIdentity>
<username>user</username>
<password>password</password>
</serverIdentity>
</authentication>
Where "myComputer.intranet.com" is my computer's name within my corporate network.
Attribute 'hostname' is not allowed to appear in element 'ntlm'

Response from IBM Service Request:
The username used to authenticate with NTLM-enabled back-end system must be left padded with the windows domain name followed by a \, and the username.
<serverIdentity>
<username>domain\user</username>
<password>password</password>
</serverIdentity>
This works with hard-coded serverIdentity feature.
Due to security governance in my company, there can't be "generic" server identity. So i have to forward the end users' credentials to back-end systems to authenticate.
How to do this with Worklight authentication mecanisms (adapter-based for instance), where can i set the domain for my username?
Can i mix several kinds of security realms depending on adapters?

Related

NiFi: LDAP Authentication Multiple DN Issue

I Installed nifi-1.13.2
and I need to authenticate with LDAP
but there is some issue
when I want to use multiple account in different "OU"
I get this error
"Unable to validate the supplied credentials. Please contact the system administrator."
this is my login-identity-providers.xml:
login-identity-providers.xml
this is my LDAP Server table:
LDAP
I found The Solution
you should change ldap port to 3268
like this
<property name="Url">ldap://10.1.21.2:3268</property>
<property name="User Search Base">DC=COM</property>
this port is for Global catalog and mostly use for authentication

In Jetty, how to support certificate authentication only on a subset of API

I'm building a web service and are using Jetty as the server. For some of the API-s this service provides, we want them to be authenticated by certificate. So I have following code:
SslContextFactory sslContextFactory = new SslContextFactory();
sslContextFactory.setWantClientAuth(true);
Server server = new Server(pool);
ServerConnector sslConnector = new ServerConnector(server,
new SslConnectionFactory(sslContextFactory, "HTTP/1.1"),
new HttpConnectionFactory(httpsConfig));
server.addConnector(sslConnector);
Now, my service also has a corresponding web UI. When users access the web UI which in turn calls backend API-s, the browser prompts the user for a cert. I don't want this to happen because the API called by the web UI do not support certificate authentication. However, the above code is configuring in a global way. Is there any way to resolve this ?
Update:
I've looked at other server implementations.
For example, in ASP.NET, we can define following config:
<location path="some-api">
<system.webServer>
<security>
<access sslFlags="SslNegotiateCert"/>
</security>
</system.webServer>
</location>
There is also similar settings in Apache Http Server
So it seems SSL/TLS itself isn't prohibiting me from doing so. Are there any Jetty settings that I have missed ?
The TLS level certificate validation occurs before the HTTP Request is even sent/processed/parsed.
It's not possible to skip that validation based on information after the TLS handshake.
You could, as an alternate method, just put the certificate validation on a different port on the same machine (with a different ServerConnector configuration), leaving the normal connector without client certificate validation.

unable to set security domain via jboss-web.xml

We have an app that is being deployed as an ear. Within this ear, there is a war that needs to use a specific security domain.
To achieve this, we have configured the standalone-full-ha.xml with the following security section
<security-domain name="ourDomain" cache-type="default">
<authentication>
<login-module code="blah.blah.OurDomain" flag="required" />
</authentication>
</security-domain>
ear/war/WEB-INF/jboss-web.xml is configured as follows:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<security-domain>Quark</security-domain>
<disable-audit>true</disable-audit>
</jboss-web>
With this configuration, the app tries to authenticate against the "other" domain which is there in JBoss by default.
log entries as follows:
TRACE [org.jboss.security] (http-/127.0.0.1:8080-6) PBOX000224: End getAppConfigurationEntry(other), AuthInfo: AppConfigurationEntry[]:
[0]
LoginModule Class: org.jboss.as.security.remoting.RemotingLoginModule
ControlFlag: LoginModuleControlFlag: optional
Options:
name=password-stacking, value=useFirstPass
[1]
LoginModule Class: org.jboss.as.security.RealmDirectLoginModule
ControlFlag: LoginModuleControlFlag: required
Options:
name=password-stacking, value=useFirstPass
When trying to define this as part of the ear in ear/META-INF/jboss-app.xml, that made the whole thing blow up pretty spectacularly - so figured that was less likely to be the way to resolve this.
If the default security domain is changed to ourDomain however, it all works as expected.
This doesn't seem to be a big deal - however, it feels better to be able to leave as much of the configuration in the app as possible.
Any pointers to resolve this appreciated.
Your security domain name specified in jboss-web.xml needs to match the name of some security domain in your JBoss config, in your case the web descriptor specifies Quark while the security subsystem defined domain named ourDomain.
Whenever JBoss can not find the security domain you request in your jboss-web.xml, it will fallback to the default security domain, which in case of 7.x is named other.

How to set user principal name of service identity of an STS issuer for a ws-federation binding by config?

How can I specify the service identity principal name in the WCF client config for the issuer STS when binding using WS-Federation?
I have an application pool running under a domain account on a front end server trying to authenticate using federation to backend services on an app server (running under domain accnts) using an STS also running on the app server and under a domain account.
In order to use Kerberos correctly I need to set the userprincipal name of the STS on the frontend client. I can't see how to do that.
I am experiencing a connected problem, which is that fallback to NTLM does not work when the issuer is specified using FQDN, and Kerberos fails (SSPI negotiation failed) I think because I have no issuer principal name in the config. If I set the issuer using IP address instead, then authentication to STS succeeds using NTLM, I think, so I have a workaround.
The STS is issuing tokens on the basis of Windows auth on that endpoint. It has other endpoints for forms-type auth and so on.
Possibly a related problem on our network is that silverlight clients that call back to web services are not working without the servers being manually added to Local Intranet zone in IE. Seems as though for some reason the app servers are not considered as being on same domain. Any clues much appreciated!
I found the solution regarding setting the user principal name of the STS. I just needed to set it in the issuer element of the federation binding:
OK, don't know why I couldn't find this before, but first thing Monday morning the answer pops up immediately:
http://msdn.microsoft.com/en-us/library/aa347735.aspx
The issuer element of the wsfederation is an endpoint config that allows you to set the user principal name within it.
The schema from the link above is here:
<issuer address="Uri" >
<headers>
<add name="String"
namespace="String" />
</headers>
<identity>
<certificate encodedValue="String"/>
<certificateReference findValue="String"
isChainIncluded="Boolean"
storeName="AddressBook/AuthRoot/CertificateAuthority/Disallowed/My/Root/TrustedPeople/TrustedPublisher"
storeLocation="LocalMachine/CurrentUser"
x509FindType=System.Security.Cryptography.X509certificates.X509findtype/>
<dns value="String"/>
<rsa value="String"/>
<servicePrincipalName value="String"/>
<usePrincipalName value="String"/>
</identity>
</issuer>
Regarding the network issues, this was a DNS problem. PTR used instead of aliases.

WCF Client - 407 Proxy Authentication Required while running webservice

I've created simple WinForms app that uses free webservice http://www.webservicemart.com/uszip.asmx. But this app fails to use service operation with error:
The remote server returned an unexpected response: (407) Proxy Authentication Required (The ISA Server requires authorization to fulfill the request. Access to the Web Proxy service is denied)
Code that creates proxy and triggers service operation:
ChannelFactory<ServiceReference1.USZipSoap> proxy = new ChannelFactory<ServiceReference1.USZipSoap>("USZipSoap");
ServiceReference1.USZipSoap client = proxy.CreateChannel();
string str = client.ValidateZip("12345");
MessageBox.Show(str);
Is this problem with a network of my company or this is a proxy on the side of webservicemart.com?
I've googled a lot of information on changing configuration files, creating a custom binding, etc. But I feel the lack of more basic understanding... If this error is about ISA server of our corporate network then what configuration should I make to ISA Server to not restrict me from using external webservices?
In your binding configuration make sure that useDefaultWebProxy is set to true - it will use configuration you have found in IE. In your configuration file add following snippet to ensure default your credentials are used for authentication on the proxy server:
<system.net>
<defaultProxy useDefaultCredentials="true" />
</system.net>
This worked for me... replacing 10.1.0.50 and the port number with your proxy server's IP
<system.net>
<defaultProxy useDefaultCredentials="true">
<proxy usesystemdefault="False" proxyaddress="http://10.1.0.50:8080" bypassonlocal="True" />
</defaultProxy>
</system.net>
Seems like all the traffic in your company is being redirected through a proxy. Can you browse to the web service from your IE and see its wsdl and invoke the test page to see some results. If that is the case then try adding the below section into your web.config:
<system.net>
<defaultProxy>
<proxy proxyaddress="<your proxy address>" bypassonlocal="true" />
</defaultProxy>
</system.net>
You can find the proxy address from the settings of your IE.
NOTE: When you move to different environments then you need to make sure that its the same case else you need to remove the above configuration.
You can set the web.config of the service to allow to use the proxy settings as defined in Internet Explorer.
Sometime in the future.
WebRequest.DefaultWebProxy.Credentials = CredentialCache.DefaultNetworkCredentials;