CXF STS client throws Request does not contain Security header/Response message does not contain WS-Addressing properties [duplicate] - spring

When adding an STS reference, I input the my windows azure federation metadata URL and it gives me the error in the title. It works if I create a new namespace, but a lot of stuff is configured on the current namespace, so I can't delete it.

So for anyone that would get this error, it's a simple fix.
You need a X.509 certificate configured as primary in your ACS namespace.
To do this you go under your acs configurations, in certificates and keys then you add a X.509 by uploading a .pfx file to the server and entering the password.
You might also need a symmetric key also set as primary depending on your configuration.

Related

Spring Cloud Config Server - Connect to Github account with 2FA

I'm trying to create a Spring Cloud Config Server to retrieve configuration files from a private GitHub repository. My GitHub account has 2 Factor Authentication activated so I wasn't expecting the below configuration to work, which it didn't but I can't find any documentation to suggest what I need to do in order to make it work.
What configuration do I need to set that will allow the connection to work?
spring.cloud.config.server.git.uri=https://github.com/DanBonehill/photo-app-config
spring.cloud.config.server.git.username=USERNAME
spring.cloud.config.server.git.password=PASSWORD
Error
org.eclipse.jgit.api.errors.TransportException: https://github.com/DanBonehill/photo-app-config: not authorized
What you could try and do (have not tested this), is create a personal access token from the Github console.
Then configure
spring.cloud.config.server.git.username=<yourusername>
spring.cloud.config.server.git.password=<yourtoken>
Instead of using username and password you should use an ssh key, the official documentation can guide you through it!
Basic authentication using a password to Git is deprecated and will soon no longer work. Visit https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more information around suggested workarounds and removal dates.
you solve this in 2 minutes, this problem is because at August 13, 2021 the github update the login form, to solve this.
1) login in your gitHub folow this path: Settings > Developer settings > Personal access tokens > Generate new token
2) Now set a long time to expiration token, check the "repo" to allow access repository with this token, and Generate token.
3) Now skill your github password because this token created is your new password, replace this at all application, server, terminal that need to access github.
4) Now configure your spring configuration server, this is a content of file "application.properties" of spring configuration server at path /src/main/resources/application.properties.
spring.cloud.config.server.git.uri= https://github.com/"username"/"repository" //your githur repository
spring.cloud.config.server.git.search-paths= myFilesFolder /if your files is into some folder
spring.cloud.config.server.git.username= testUsername // your username
spring.cloud.config.server.git.password= gti_FdsweecSoUSHPsdfw //Here is your new token created

How do I find my server's public key info to do certificate pinning in OkHttp?

I have a server with a custom certificate on it issued by my own personal certificate authority. It's not on a public domain so it's not possible to use a standard certificate authority. I want to get an Android client to connect to this server using OkHttp. According to the docs, the code should look like this:
CertificatePinner certificatePinner = new CertificatePinner.Builder()
.add("myserver.com", "sha256/afwiKY3RxoMmLkuRW1l7QsPZTJPwDS2pdDROQjXw8ig=")
.build();
Where the SHA256 hash is, quoting the docs: "a hash of a certificate’s Subject Public Key Info, base64-encoded and prefixed with either sha256/ or sha1/". I have the cert and the key files for the server, but how can I get the required hash?
I'm using OkHttp 3.
Try making a request to your server with the configuration above to see how that fails. The exception should tell you which pins were found.
You must do certificate pinning in coordination with your server team! Otherwise a change they make will prevent your client from being able to reach the server.

Certificate file ldap-server.crt does not exist

when I tried Single Sign on to the wso2 API manager using the shibboleth IDP as the federated Identity provider,
a login error occurred as
ldap-server.crt doesn't exist.
Can you give me any Suggestions?
I am not much aware of Shibboleth IDP however i have used other SSO's and what i did was to import the certificates .crt in client-truststore.jks file.So have you tried importing the certificate ldap-server.crt in client-trustore.jks file .Hope this gives you an idea

How to share a public key for OAuth2 JWT validation?

I am implementing an app that connects to an OAuth2 server and it gets back a Json Web Token (JWT). I am passing the token along and I want to independently validate that the token came from the issuing source.
I can do this, no problem, with the public key from the issuing source. I have it available to me for now. Everything works.
But what if the OAuth server changes the signing key? How does the validating app get the new key? Is there a "best practices" convention for sharing the public key from an OAuth2 server? Do we just expose it from an endpoint on the auth server?
There's no solution that is standardized as part of the OAuth 2.0 protocol suite (today).
It was considered to be a single-domain problem that would be solved in various ways that were considered to be out of scope for the core OAuth specifications (much like the API between Resource Server and Authorization Server is/was), and much like any PKI based mechanism in general works today.
But OpenID Connect is a cross-domain SSO protocol that was built on top of OAuth 2.0, which also defined a more standardized option of dealing with key distribution in the form of JWKs URIs as part of the Discover, see the jwks_uri entry at:
REQUIRED. URL of the OP's JSON Web Key Set [JWK] document. This
contains the signing key(s) the RP uses to validate signatures from
the OP. The JWK Set MAY also contain the Server's encryption key(s),
which are used by RPs to encrypt requests to the Server. When both
signing and encryption keys are made available, a use (Key Use)
parameter value is REQUIRED for all keys in the referenced JWK Set to
indicate each key's intended usage. Although some algorithms allow the
same key to be used for both signatures and encryption, doing so is
NOT RECOMMENDED, as it is less secure. The JWK x5c parameter MAY be
used to provide X.509 representations of keys provided. When used, the
bare key values MUST still be present and MUST match those in the
certificate.
This would expose the key material over HTTPs protected channel, effectively leveraging the SSL CA for publishing and rollover of JWT signing key material.
At some point the jwks_uri definition may be part of the standardized OAuth 2.0 protocol extensions as well, but for now you'd have to rely on a custom agreement between Client and Authorization Server to do so. That may not be too hard to implement yourself though.
You may get lucky if your Authorization Server happens to be an OpenID Connect provider as well and uses the same key material for signing ID tokens as well as JWT access tokens.
Updated 4/22/2019: the Authorization Server metadata document is now also standardized it its own OAuth 2.0 extension OAuth 2.0 Authorization Server Metadata RFC8414

Why are there no WS-Security/WS-Policy declarations in the Amazon EC2 WSDL?

The AWS EC2 SOAP API documentation discusses securing the SOAP message using the WS-Security standard (specifically the X509 token profile).
However, the WSDL linked from the page doesn't have any WS-Security/WS-Policy declarations. What am I missing? Is the requirement to use X509 meant to be conveyed completely out-of-band through this documentation? That seems odd. I noticed that the WSDL was updated 2012-06-01 - is it possible that the WS-Security requirement has been relaxed?
You'll need to request a certificate for SOAP operations under your Amazon account. It will provide two files (private key and cert, both are PEM files).
Follow this link, login if needed and take a look into the "Access Credentials
" section. There's a "X.509 Certificates" tab, where you can download existing certificates or create a new one.

Resources