I'm using Liberty JAAS CustomLoginModule to customize my login module for authentication. I already pass the authentication but failed in authorization because I cannot get user registry. From the trace I can see when I use
this.userRegistry = this.getUserRegistry();
it will issue:
java.lang.NullPointerException
at com.ibm.ws.security.authentication.internal.jaas.JAASServiceImpl.getUserRegistry(JAASServiceImpl.java:122)
However, from the trace, I can see my info configured in server.xml has been put into Liberty.
*{com.ibm.ws.security.registry.UserRegistry}={user.0.password=*****, user.0.config.referenceType=com.ibm.ws.security.registry.basic.config.user, realm=zosConnect, service.scope=bundle, component.name=com.ibm.ws.security.registry.basic.internal.BasicRegistry, group.0.member.0.name=Fred, user.0.name=Fred, config.source=file, group.0.config.referenceType=com.ibm.ws.security.registry.basic.config.group, id=basic1, service.pid=com.ibm.ws.security.registry.basic.config_39, group.0.name=ADMIN, service.id=260, service.bundleid=31, config.overrides=true, com.ibm.ws.security.registry.type=Basic, component.id=73, config.id=com.ibm.ws.security.registry.basic.config[basic1], group.0.member.0.config.referenceType=com.ibm.ws.security.registry.basic.config.group.member, service.factoryPid=com.ibm.ws.security.registry.basic.config, ignoreCaseForAuthentication=false, service.vendor=IBM, config.displayId=basicRegistry[basic1]}
[5/20/18 15:47:01:012 GMT] 00000015 id=d64f0d3e om.ibm.ws.security.registry.internal.UserRegistryServiceImpl >*
So, is there any way to getUserRegistry? Or is there any way to make it pass authorization?
Looking forward to the answer, thanks a lot.
You should be using the RegistryHelper.getUserRegistry( ) method to get the UR - more info at https://www.ibm.com/support/knowledgecenter/SSAW57_liberty/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/rwlp_sec_apis.html
Regards,
Ut Le
Related
Scenerio:
Upgraded Spinnaker to 1.12.0. No other config changes that would impact this integration (we had to modify an s3 IAM because it quit working). Okta integration stopped working. Public key was reissued during install process for the ingress, may be relevant?
SAML-TRACE shows payload getting to okta and back
Spinnaker throws two different errors depending on browser and how I get there.
Direct link to deck url: (500) No IDP was configured, please update included metadata with at least one IDP (seen in browser and gate)
Okta "chicklet" in okta dashboard: (401) Authentication Failed: Incoming SAML message is invalid
Config details (again none of this changed):
Downloading metadata directly
JKS is being leveraged and is valid
service url is confirmed
alias for JKS is confirmed
I had this issue as well when upgrading from 1.10.13 to 1.12.2. I found lots of these error messages in Gate's logs:
2019-02-19 05:31:30.421 ERROR 1 --- [.0-8084-exec-10] o.a.c.c.C.[.[.[/].[dispatcherServlet] : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw e
xception [org.opensaml.saml2.metadata.provider.MetadataProviderException: No IDP was configured, please update included metadata with at least one IDP] with root cause
org.opensaml.saml2.metadata.provider.MetadataProviderException: No IDP was configured, please update included metadata with at least one IDP
at org.springframework.security.saml.metadata.MetadataManager.getDefaultIDP(MetadataManager.java:795) ~[spring-security-saml2-core-1.0.2.RELEASE.jar:1.0.2.RELEASE]
at org.springframework.security.saml.context.SAMLContextProviderImpl.populatePeerEntityId(SAMLContextProviderImpl.java:157) ~[spring-security-saml2-core-1.0.2.RELEASE.jar
:1.0.2.RELEASE]
at org.springframework.security.saml.context.SAMLContextProviderImpl.getLocalAndPeerEntity(SAMLContextProviderImpl.java:127) ~[spring-security-saml2-core-1.0.2.RELEASE.ja
r:1.0.2.RELEASE]
at org.springframework.security.saml.SAMLEntryPoint.commence(SAMLEntryPoint.java:146) ~[spring-security-saml2-core-1.0.2.RELEASE.jar:1.0.2.RELEASE]
at org.springframework.security.web.access.ExceptionTranslationFilter.sendStartAuthentication(ExceptionTranslationFilter.java:203) ~[spring-security-web-4.2.9.RELEASE.jar
:4.2.9.RELEASE]
...
After downgrading back to 1.10.13, I upgraded to the next version, 1.11.0, and found that's when the issue started. Eventually, I looked at Gate's logs from the launch of the Container and found:
2019-02-20 22:31:40.132 ERROR 1 --- [0.0-8084-exec-3] o.o.s.m.provider.HTTPMetadataProvider : Error retrieving metadata from https://000000000000.okta.com/app/00000000000000000/sso/saml/metadata
javax.net.ssl.SSLException: Error in hostname verification
at org.opensaml.ws.soap.client.http.TLSProtocolSocketFactory.verifyHostname(TLSProtocolSocketFactory.java:241) ~[openws-1.5.4.jar:na]
at org.opensaml.ws.soap.client.http.TLSProtocolSocketFactory.createSocket(TLSProtocolSocketFactory.java:186) ~[openws-1.5.4.jar:na]
at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707) ~[commons-httpclient-3.1.jar:na]
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387) ~[commons-httpclient-3.1.jar:na]
...
This lead me to realize that the TLS Certificate was being rejected by Gate. Not sure why it suddenly started failing the check. Up to this point, I had it configured as:
$ hal config security authn saml edit --metadata https://000000000000.okta.com/app/00000000000000000/sso/saml/metadata
I ended up downloading the metadata file and redeploying with halyard.
$ wget https://000000000000.okta.com/app/00000000000000000/sso/saml/metadata
$ hal config security authn saml edit --metadata "${PWD}/metadata"
$ hal config version edit --version 1.12.2
$ hal deploy apply
Opened up a private browser window as suggested by the Spinnaker documentation and Gate started redirecting to Okta correctly again.
Issue filed, https://github.com/spinnaker/spinnaker/issues/4017.
So I ended up finding the answer. The tomcat config changed apparently in spinnaker in later versions for gate.
I created this snippet in ~/.hal/default/profiles/gate-local.yml
server:
tomcat:
protocolHeader: X-Forwarded-Proto
remoteIpHeader: X-Forwarded-For
internalProxies: .*
Deployed spinnaker and it was back to working.
I'm setting up Shibboleth to use SAML 2.0. This setup contains reverse proxy using Nginx to Jetty 9.49 which points to shibboleth idp.war file.
For testing, I'm using the django Service provider from this example here.
I'm using self-sign certificates.
I can access both https://idp.localhost/idp/shibboleth and https://idp.localhost/idp/status, but not https://idp.localhost/idp/profile/SAML2/POST/SSO. From shibboleth log file, I'm getting this error each time I browse https://idp.localhost/idp/profile/SAML2/POST/SSO:
2018-04-25 18:20:47,746 - ERROR
[org.opensaml.saml.common.binding.security.impl.ReceivedEndpointSecurityHandler:200]
- Message Handler: SAML message intended destination endpoint 'https://idp.localhost/idp/profile/SAML2/POST/SSO' did not match the
recipient endpoint 'http://idp.localhost/idp/profile/SAML2/POST/SSO'
==> idp-warn.log <== 2018-04-25 18:20:47,746 - ERROR [org.opensaml.saml.common.binding.security.impl.ReceivedEndpointSecurityHandler:200]
- Message Handler: SAML message intended destination endpoint 'https://idp.localhost/idp/profile/SAML2/POST/SSO' did not match the
recipient endpoint 'http://idp.localhost/idp/profile/SAML2/POST/SSO'
==> idp-process.log <== 2018-04-25 18:20:47,748 - WARN [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:202] -
Profile Action WebFlowMessageHandlerAdaptor: Exception handling
message org.opensaml.messaging.handler.MessageHandlerException: SAML
message failed received endpoint check at
org.opensaml.saml.common.binding.security.impl.ReceivedEndpointSecurityHandler.checkEndpointURI(ReceivedEndpointSecurityHandler.java:202)
==> idp-warn.log <== 2018-04-25 18:20:47,748 - WARN [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:202] -
Profile Action WebFlowMessageHandlerAdaptor: Exception handling
message org.opensaml.messaging.handler.MessageHandlerException: SAML
message failed received endpoint check at
org.opensaml.saml.common.binding.security.impl.ReceivedEndpointSecurityHandler.checkEndpointURI(ReceivedEndpointSecurityHandler.java:202)
==> idp-process.log <== 2018-04-25 18:20:47,749 - WARN [org.opensaml.profile.action.impl.LogEvent:105] - A non-proceed event
occurred while processing the request: MessageAuthenticationError
==> idp-warn.log <== 2018-04-25 18:20:47,749 - WARN [org.opensaml.profile.action.impl.LogEvent:105] - A non-proceed event
occurred while processing the request: MessageAuthenticationError
Where did I go wrong?
I think that a request was done in HTTPS and a response returned in clear HTTP.
This kind of problem sometimes happen when jetty was non installed from source or with other corrupted packages. It's difficult to diagnose in this situation.
Try to compile jetty from source, clean first your old installation.
I've also build up a complete IDP/SP setup procedure with apache2 or nginx/ tomcat or jetty setup here, with ansible:
https://github.com/peppelinux/Ansible-Shibboleth-IDP-SP-Debian9
It takes 4 minutes to give you what you expect, It needs an existing LDAP installation.
I have noticed following error in my region server logs:
org.apache.hadoop.security.token.SecretManager$InvalidToken: access control error while attempting to set up short-circuit access to /apps/hbase/data/data/default/my-table/eb512b4b9f9fa9cb2a1a3930d9c9f18b/r/df1694a4542f419992f86b219541fb6fBlock token with block_token_identifier (expiryDate=1519482398334, keyId=1283446178, userId=hbase, blockPoolId=BP-1872413417-101.33.253.88-1458393583173, blockId=1133036852, access modes=[READ]) is expired.
at org.apache.hadoop.hdfs.BlockReaderFactory.requestFileDescriptors(BlockReaderFactory.java:591)
at org.apache.hadoop.hdfs.BlockReaderFactory.createShortCircuitReplicaInfo(BlockReaderFactory.java:490)
at org.apache.hadoop.hdfs.shortcircuit.ShortCircuitCache.create(ShortCircuitCache.java:782)
at org.apache.hadoop.hdfs.shortcircuit.ShortCircuitCache.fetchOrCreate(ShortCircuitCache.java:716)
at org.apache.hadoop.hdfs.BlockReaderFactory.getBlockReaderLocal(BlockReaderFactory.java:422)
at org.apache.hadoop.hdfs.BlockReaderFactory.build(BlockReaderFactory.java:333)
at org.apache.hadoop.hdfs.DFSInputStream.actualGetFromOneDataNode(DFSInputStream.java:1118)
at org.apache.hadoop.hdfs.DFSInputStream.fetchBlockByteRange(DFSInputStream.java:1056)
at org.apache.hadoop.hdfs.DFSInputStream.pread(DFSInputStream.java:1411)
at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:1374)
at org.apache.hadoop.fs.FSDataInputStream.read(FSDataInputStream.java:89)
at org.apache.hadoop.hbase.io.hfile.HFileBlock$AbstractFSReader.readAtOffset(HFileBlock.java:1380)
at org.apache.hadoop.hbase.io.hfile.HFileBlock$FSReaderImpl.readBlockDataInternal(HFileBlock.java:1591)
at org.apache.hadoop.hbase.io.hfile.HFileBlock$FSReaderImpl.readBlockData(HFileBlock.java:1470)
at org.apache.hadoop.hbase.io.hfile.HFileReaderV2.readBlock(HFileReaderV2.java:437)
at org.apache.hadoop.hbase.io.hfile.HFileBlockIndex$BlockIndexReader.loadDataBlockWithScanInfo(HFileBlockIndex.java:259)
at org.apache.hadoop.hbase.io.hfile.HFileReaderV2$AbstractScannerV2.seekTo(HFileReaderV2.java:634)
at org.apache.hadoop.hbase.io.hfile.HFileReaderV2$AbstractScannerV2.seekTo(HFileReaderV2.java:584)
at org.apache.hadoop.hbase.regionserver.StoreFileScanner.seekAtOrAfter(StoreFileScanner.java:247)
at org.apache.hadoop.hbase.regionserver.StoreFileScanner.seek(StoreFileScanner.java:156)
at org.apache.hadoop.hbase.regionserver.StoreScanner.seekScanners(StoreScanner.java:363)
at org.apache.hadoop.hbase.regionserver.StoreScanner.<init>(StoreScanner.java:217)
at org.apache.hadoop.hbase.regionserver.HStore.getScanner(HStore.java:2003)
at org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.<init>(HRegion.java:5338)
at org.apache.hadoop.hbase.regionserver.HRegion.instantiateRegionScanner(HRegion.java:2494)
at org.apache.hadoop.hbase.regionserver.HRegion.getScanner(HRegion.java:2480)
at org.apache.hadoop.hbase.regionserver.HRegion.getScanner(HRegion.java:2462)
at org.apache.hadoop.hbase.regionserver.HRegion.get(HRegion.java:6527)
at org.apache.hadoop.hbase.regionserver.HRegion.get(HRegion.java:6506)
at org.apache.hadoop.hbase.regionserver.RSRpcServices.doNonAtomicRegionMutation(RSRpcServices.java:579)
at org.apache.hadoop.hbase.regionserver.RSRpcServices.multi(RSRpcServices.java:2031)
at org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32213)
at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2114)
at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:101)
at org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:130)
at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:107)
at java.lang.Thread.run(Thread.java:745)
2018-02-24 20:03:10,947 INFO [RW.default.readRpcServer.handler=151,queue=38,port=16020] hdfs.DFSClient: Access token was invalid when connecting to /101.32.65.239:50010 : org.apache.hadoop.security.token.SecretManager$InvalidToken: access control error while attempting to set up short-circuit access to /apps/hbase/data/data/default/my-table/eb512b4b9f9fa9cb2a1a3930d9c9f18b/r/df1694a4542f419992f86b219541fb6fBlock token with block_token_identifier (expiryDate=1519482398334, keyId=1283446178, userId=hbase, blockPoolId=BP-1872413417-101.33.253.88-1458393583173, blockId=1133036852, access modes=[READ]) is expired.
I see config related to these are already tweaked by us.
dfs.client.read.shortcircuit.streams.cache.expiry.ms
300000
hdfs-default.xml
dfs.client.read.shortcircuit.streams.cache.size
4096
hdfs-site.xml
I also see a JIRA raised by Nick Dimiduk-2 already facing this, which is still open and in the comments have the config suggested by a user facing same issue, which we are also using,
Anyone faced this issue or knows about it and have any resolution/suggestion for this?
I placed plugin manager in "lib\ext" folder and tried to open it showed error:
java.io.IOException: Repository responded with wrong status code: 407
Jmeter version - 3.3
Plugin version - 0.16
Jmeter is invoked from command line by using the following parameters:
C:\Users\princen\Performance Testing\Software\apache-jmeter-3.3\bin\jmeter.bat -H Proxyserver -P 1234 -u princen -a ***
Parameters modified as suggested here
JVM_ARGS="-Dhttps.proxyHost=Proxyserver -Dhttps.proxyPort=1234 -Dhttp.proxyUser=princen -Dhttp.proxyPass=***" C:\Users\princen\Performance Testing\Software\apache-jmeter-3.3\bin\jmeter.bat
Above try gives the following error message
Windows cannot find "JVM_ARGS="-Dhttps.proxyHost=Proxyserver -Dhttps.proxyPort=1234 -Dhttp.proxyUser=princen -Dhttp.proxyPass=***
When I tried to changes command to the following:
C:\Users\princen\Performance Testing\Software\apache-jmeter-3.3\bin\jmeter.bat -Dhttps.proxyHost=Proxyserver -Dhttps.proxyPort=1234 -Dhttp.proxyUser=princen -Dhttp.proxyPass=***
I received an error:
java.io.IOException: Repository responded with wrong status code: 407
Can someone please correct parameters required to load the plugin manager?
Ensure you use last version of jmeter-plugins download manager.
Regarding your parameters, you're mixing different configurations, just set (for both http and https):
JVM_ARGS="-Dhttps.proxyHost=myproxy.com -Dhttps.proxyPort=8080 -Dhttps.proxyUser=john -Dhttps.proxyPass=password -Dhttp.proxyHost=myproxy.com -Dhttp.proxyPort=8080 -Dhttp.proxyUser=john -Dhttp.proxyPass=password"
Where password is your real password.
None of above methods working for me. Its really tough to work with Java(due to Loadrunner background). I added Ultimate thread alone and its working fine.
Thank you all for your inputs..
JMeter is using the official proxy configuration from Oracle (like here: https://memorynotfound.com/configure-http-proxy-settings-java/)
The problem is that the jmeter documentation is wrong about the password parameter: it should be http.proxyPassword not http.proxyPass.
Also you must use the https. properties for secured urls you want to access using the proxy. And the http. properties for non secured.
I am trying to have my application authenticate using AD credentials. I am using kinit to test after creating the krb5.ini file. I believe all the realm information is correct in the ini file but continue to receive the below error when testing with kinit.
Exception: krb_error 0 Cannot find any provider supporting ARCFOUR No error
KrbException: Cannot find any provider supporting ARCFOUR
at
sun.security.krb5.internal.crypto.ArcFourHmacEType.encrypt(ArcFourHm
cEType.java:68)
at
sun.security.krb5.internal.crypto.ArcFourHmacEType.encrypt(ArcFourHm
cEType.java:60)
at sun.security.krb5.EncryptedData.<init>(EncryptedData.java:122)
at sun.security.krb5.KrbAsReq.init(KrbAsReq.java:355)
at sun.security.krb5.KrbAsReq.<init>(KrbAsReq.java:180)
at sun.security.krb5.internal.tools.Kinit.<init>(Kinit.java:253)
at sun.security.krb5.internal.tools.Kinit.main(Kinit.java:107)
Caused by: java.security.NoSuchAlgorithmException: Cannot find any provider
suporting ARCFOUR
at javax.crypto.Cipher.getInstance(DashoA13*..)
at
sun.security.krb5.internal.crypto.dk.ArcFourCrypto.encrypt(ArcFourCrpto.java:279)
You need to enable RC4-HMAC in both your krb5.ini config and the conf/security/java.security
I think RC4 got blacklisted in Oracle JDK (>= 1.8.u060) for known insecurities together with MD5, but it is strictly required for key exchange by the MS Active Directory Kerberos implementation.
Maybe you have to re-enable it by removing RC4 from jdk.tls.disabledAlgorithms and jdk.certpath.disabledAlgorithms of your JDKs conf/security/java.security.
See https://www.java.com/en/configure_crypto.html for more information.