From what I have found OneLogin test connectors by default do not require a signed Authnrequest. The Authnrequest made with HTTP-Redirect works fine without a signature. I am able to authenticate my user through OneLogin, and process the SAML response.
At this point I am trying to test code that signs the AuthNRequest. Based on the specifications https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf the HTTP-Redirect method supports a signed AuthNRequest. The url parameters would be "SAMLRequest=request&SigAlg=algorithm&Signature=signature". I don't have a need for RelayState so it has been left out of the example. The spec says the signature for the HTTP-Redirect method would be created using the query string parameters "SAMLRequest=request&SigAlg=algorithm", signed using the algorithm specified in the query string. So the request itself is not signed. I am signing using a self-signed certificate. I have passed all the query string values to the OneLogin connector, and each time the AuthNRequest is processed by OneLogin successfully. However, I have modified the signature value to not be valid, and even left it blank to hopefully have it fail and the AuthNRequest is processed by OneLogin.
FYI - I tried using https://www.samltool.com/sign_authn.php to create the signed AuthNRequest to make sure I was doing it correctly, but it only appears to provide the HTTP-Post, and not the HTTP-Redirect AuthNRequest.
I have the following questions:
Does OneLogin support a signed AuthNRequest through HTTP-Redirect?
Is there a way to setup a test connector to require a signed AuthNRequest?
How would I inform OneLogin about the public key from my certificate that was used to sign the AuthNRequest?
Onelogin ( and other IDaaS ) don't support signed requests. I've never determined why that's the case but the direct answer is there's no support for that in Onelogin.
Related
I have a basic question on setting up trust between a SP and IDP.
Usually a two way trust is required when we setup an IDP with SP by uploading certificates on either side.
Is signing certificate from SP mandatory to be configured in the IDP side ?
Best Regards,
Saurav
You only need a signing keypair on the SP side if you send the subject in the AuthnRequest, and your IdP utilizes the information when provided. If your SP isn't sending the subject attribute or your IdP won't consume it, you don't need it.
The defined SAML 2.0 specifications doesn't mandate that the request is signed.
4.1.3.3 <AuthnRequest> Is Issued by Service Provider to Identity Provider
...The <AuthnRequest> message MAY be signed, if authentication of the request issuer is required.
You can check with your Identity Provider documentation, but for example, Microsoft Azure AD does not validate signed requests, and there's no way to upload a request signing certificate.
I'm working on a SPA application, and I'm using the recommended implicit flow and I'm able to get access_token and id_token. As I need more than the profile info, I've created a separate endpoint to return the user profile information (along with all the other information that's specific to our business) and this endpoint is protected, and can be accessed only with an access_token as the bearer token. Right after getting access_token in SPA, I call this endpoint to get all the user information (which includes first name, last name etc., that gets displayed on the UI). If there is any problem with the returned id_token and access_token pair, the user profile info endpoint call would fail. So, do I really need to validate the id_token? as I'm not relying on any information within that token.
For authenticating against external login provider or authorization code flow, validating the id_token makes sense, but in my case I'm not sure about it.
According to OpenID spec:
When using the Implicit Flow, the contents of the ID Token MUST be validated in the same manner as for the Authorization Code Flow, as defined in Section 3.1.3.7, with the exception of the differences specified in this section.
1. The Client MUST validate the signature of the ID Token according to JWS [JWS] using the algorithm specified in the alg Header Parameter of the JOSE Header.
2. The value of the nonce Claim MUST be checked to verify that it is the same value as the one that was sent in the Authentication Request. The Client SHOULD check the nonce value for replay attacks. The precise method for detecting replay attacks is Client specific.
Why don't you utilise response_type parameter in authorisation request. By changing its value, you can alter what you receive for authorisation response.
Identity documentation mention about possible response type values. Following is an extraction from their documentation,
As you can see, if you do not want SPA to receive the id token, you can set the response_type value to token. If you do so you will only get an access token, which is enforced by OAuth 2.0 specification. (See the OAuth 2.0's implicit flow response_type explanation from here). Note that when you use response_type=token , you are using OAuth 2.0 (not OIDC)
I don't see any wrong in your approach as long as you utilise features enabled by respective protocols.
Kentor - Using the SampleMvcApplication with success through their StubIdp but when I try with Clareity I receive the above error.
Without knowing anything about the implementations ( Kentor, SampleMvcApplication, StubIdP, Clareity )it looks as if:
Your Identity Provider implementation does not return a 'RelayState' parameter in the body of the HTTP POST along with the SAMLResponse.
Your Identity Provider implementation has added an InResponseTo attribute in the SAMLResponse element
Your Service Provider implementation interprets this as an IdP initiated SSO since it does not see a 'RelayState' parameter
Your Service Provider throws an error since it doesn't make sense for an SAMLResponse in an IdP initiated SSO flow to have an InResponseTo. InResponseTo refers to an AuthenticationRequest which is only there in a normal SP initiated SSO.
To get more help, you should tell us a little about the implementation you are using and your configuration.
We are considering to send some session information in the SAML claims.
The session information would be something to received by the chosen (custom) authenticator, such as value of an HTTP header (X509 DN), extra information provided on the logon screen, etc ...
Currently (by default) all claims are read from the userstore (as mapped by the claim mapping).
The only way I currently found to pass the session information is to implement/overwrite the SAML2SSOManager implementation.
Is there any simpler way to pass some user attributes from the authenticator which will be handled as a claim by the default SAML2SSOManager implementation?
I see the federated authenticators use context.getSubject().getUserProperties() to pass remote claims to the SAML response. Is it a way? ( regardless I put any ClaimMapping into the userProperties and declare the claim as required, I am unable to get it out as SAML response claim)
Thank you in advance
Apparently the way to go is implementing a custom ClaimHandler as described http://pushpalankajaya.blogspot.be/2014/07/adding-custom-claims-to-saml-response.html
The local authenticator can set the claims as user properties (of the subject).
In this case extending the handleLocalClaims should be enough, not to mess with federated mapping (where federated authenticators use the subject userAttributes as well)
I am just wondering while implementing SAML SSO with Salesforce I realize that I uploaded the certificate to the SP side (i.e. Salesforce), however I can see when we send a signed SAML response it already includes the certificate.
Why is the certificate shared ahead of time with the SP?
It's all about establishing trust between systems. If you don't give SFDC your cert ahead of time, how can they trust the message you are sending is actually from your IDP? Without your cert ahead of time, they can validate that the message is intact but not who actually generated it. When you include your public key in the SAML Response, they can check that it's the same one you shared with them and it's the same one you used to generate the signature.