I am trying to integrate saml with java spring boot application. I integerated it with okta, and works fine. But when i change the config to point to actual adfs(not Okta), i get this error on adfs "MSIS0037: No signature verification certificate found for issuer 'https://xxx.mydomain.com/saml/metadata'.
I checked my SAML auth request using SAML tracer and in that issuer is https://xxx.mydomain.com/saml/metadata, but i guess it should be https://xxx.mydomain.com and i am guessing that is why i get this error. I have installed an internally generated certificate on the server, and put the public key in the metadata i have provided to the adfs team which they have inserted successfully. Can anyone guide me to how to change issuer in my saml request?
You can change the issuer in the SAML request: <saml:Issuer> https://xxx.mydomain.com</saml:Issuer>
This guide has some good samples for doing this with ADFS and spring boot: https://myshittycode.com/2016/02/18/spring-security-saml-configuring-binding-for-sending-saml-messages-to-idp/
Related
I'm trying to extend my home made OAuth2 Authorization Server with the OpenID Connect. At the moment, the Server works fine and successfully issues an access token.
What I need is that the token endpoint returns an id_token along with the access_token.
The Authorization Server is a Spring boot (2.5) app, which implements the authorization code flow using following oauth dependencies.
spring-security-oauth2
spring-security-oauth2-autoconfigure
spring-security-jwt
spring-security-oauth2-jose
Is there some standard way to configure an OAuth2 Spring Server so it provides the OpenID Connect features?
Thanks in advance for an example code and/or useful documenation.
The Spring team are working on a new OAuth server, that provides OIDC capability. It's still very early days, but it is useable.
See here for the code, that includes a set of samples:
https://github.com/spring-projects/spring-authorization-server
I am trying to use sample application for inhouse adfs now, the difference is SSOCircle idp url is not http secured, whereas the adfs url I am configuring is https secured.
I have explained my approach here
Spring saml sample application with https idp url throws exception: No IDP was configured, please update included metadata with at least one IDP
Could you please look into the same and explain me the steps to make https url working?
Thanks
One thing you need to do is add the ssl certificate to your saml keystore.
You can get this ssl certificate a couple of ways. One way is to view the idP logon form in your browser, then export the certificate using browser functionality.
Spring also provide a utility program for extracting the ssl certificate. Check out this link...
http://docs.spring.io/autorepo/docs/spring-security-saml/1.0.x-SNAPSHOT/reference/htmlsingle/#configuration-key-management-ssl-keys
I have created the Spring Authorization Server which issues JWT-s and a Resource Server which checks the JWT, its claims and permissions on the Authorization Server. To do so, I have followed this article.
My question is why I need to send the Authorization header with HTTP Basic authorization and Base64 encoded username/password (ClientId:ClientSecret) in get token request? I have seen JWT implementations where only username and password are required.
It is part of the specification, see RFC 6749:
2.3 Client Authentication
If the client type is confidential, the client and authorization server establish a client authentication method suitable for the security requirements of the authorization server. The authorization server MAY accept any form of client authentication meeting its security requirements.
Confidential clients are typically issued (or establish) a set of client credentials used for authenticating with the authorization server (e.g., password, public/private key pair).
The authorization server MAY establish a client authentication method with public clients. However, the authorization server MUST NOT rely on public client authentication for the purpose of identifying the client.
The client MUST NOT use more than one authentication method in each request.
By default Spring Security OAuth 2.0 protects the token endpoint, see OAuth 2 Developers Guide:
The token endpoint is protected for you by default by Spring OAuth in the #Configuration support using HTTP Basic authentication of the client secret.
But it seems, that you can disable the client authentication:
Spring Security OAuth 2.0 - client secret always required for authorization code grant
Is it possible to get an access_token from Spring OAuth2 server without client secret?
Spring Security OAuth 2.0 with no client_secret
That is the structure of the JWT token:
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret
)
As you are doing a JWT implementation all the 3 parts must be there: header.payload.secret
Maybe in the implementation you have seen - the server was working with Default Secret
I am new to SSO and Sping SAML extension.
i have implemented Spring SAML extension into our application where our application acts as a SP. i have following question related to our requirement.
1) I would like to understand the use of samlKeystore.jks in Spring saml extension
2) I would like to know if we can skip the use of samlKeystore.jks in any manner.
Basically the reason for this the client can give us information on Just the meta data
and nothing apart from that.if we are using samlKeystore.jks do we need anything else
If you don't need to sign SAML protocol message or encrypt SAML assertions you don't need the keystore. However some SAML Bindings mandates or at least highly recommend to sign so that the protocol messages are not tampered with at the user agent.
The keystore is used for storage of private certificates used to digitally sign messages created by the Service Provider and decrypting of messages sent from Identity Providers.
Spring SAML currently requires you to have at least a default key available, even in case it won't get used.
I've implemented SSO using Spring SAML and everything is working fine for an interaction with idp.ssocircle.com.
Now I am trying to use another identity provider. I have downloaded the metadata of the IdP and have linked it in my spring XML config. I have also uploaded the metadata of the service provider to the iDP and have linked it in the spring XML config.
I am redirected to the login page of my IdP and can successful enter my credentials. But an error like that appears "Signature did not validate against the credential's key".
There is another stackoverflow post which describes a similiar problem, see "HTTP Status 401 - Authentication Failed: Incoming SAML message is invalid" with Salesforce as IdP for implementating SSO
But I have problems to follow the solution, because my SAML response captured by Fiddler does not contain an element like "X509Certificate".
Edit(!):But I have to say that the metadata of my identity provider contains a element like "ds:X509Certificate" in "ds:keyInfo" with some content. But there also another empty "ds:keyInfo"-Element with an empty "ds:X509Data"-Element.
Is there something wrong with the configuration of the identity provider?
Can anybody tell my what is happening here?
Complete log file: https://drive.google.com/file/d/0B3RlRCEjz-cvZGQ5aldzaUc0blE/edit?usp=sharing
Thanks in advance,
Andi
It seems that the Response message is signed using a different certificate than what is included in the IdP metadata. You should ask your IdP to tell you what certificates they use for their signatures and add them to their metadata file. Based on what you say it could also be that the metadata file is simply incomplete or corrupted.
The other option is to add the certificate they provide you to the samlKeystore.jks (and remember the alias). Then define the alias as signingKey on the ExtendedMetadata of your IdP's metadata definition in Spring configuration. You can find details on using the ExtendedMetadata in the Spring SAML manual.
The fact that the key is not included in the Response message is not wrong, Spring SAML knows which keys to use from the metadata and ExtendedMetadata configuration.