I need to use SAML assertion lifetime for deciding the expiry of the API key, is there any way we can get the SAML session/assertion validity from the identity provider, I know using notonorafter attribute that value can be retrieved but can we update that value in IDP in some way?
Related
Okta's official document states that a SAML Service Provider does not store any state:
https://developer.okta.com/docs/concepts/saml/#planning-for-saml
The Service Provider doesn't know if the Identity Provider will ever complete the entire flow. Because of this, the Service Provider doesn't maintain any state of any authentication requests generated.
However, I also read that the SAML Application will generate a request ID which is unique to that particular request. And the SAML response will contain this same request ID which the application will use to figure out which request it corresponds to.
There is a contradiction between Okta's doc and the SAML concept. The application is storing the state. Is Okta's doc inaccurate or am I missing some concept over here?
I think Okta's document is misleading. As you say, one of the checks that a service provider should make is that the InResponseTo field in the SAML response matches the SAML authn request's ID. This is essentially state information the SP must remember so it can perform this check when the SAML response is received. Our SAML implementation certainly maintains state information and I would imagine most, if not all, implementations would.
is OpenAM depends on the public key of the registered IDP to versify the SAML response
or depends also on the hashing algorithm in the SAML response from IDP
like Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"
Note OpenAM version :13.0.0
OpenAM, acting as SAML SP, uses the public key enclosed in the KeyInfo element of the IdP meta data to verify the signature of the SAML response. It uses the signature algorithm chosen by the IdP, however it must be a supported signature algorithm.
In upcoming versions of AM, AM will (partially) implement the algsupport spec, and will take into account remote entity provider's metadata when signing SAML documents.
This means that as a hosted entity provider, AM will check the remote entity provider's preferred signing and digest methods, and will use the first algorithm that satisfies the key type and key size requirements.
This work has been completed as part of OPENAM-11266.
I started with Service Provider based SSO for SAML. Since the user had to enter his email before proceeding with the login, a state variable was initiated and passed on to the SSO. It comes back through the callback URL and hence was check again for the sanity purpose. It protected against CSRF attacks.
Now IdP initiated SSO doesn't allow me to set state variable at all. Login starts at Identity Provider and only an auth token is provided to the app. I do not know which user is authenticating from the beginning. If I remove the state variable check, it could trigger a CSRF attack as well.
I am also using omniauth in rails which makes state variable a compulsory param and SSO provider is auth0.
What is the way to attach state variable to IdP initiated SSO solutions?
The de-facto standard value of the RelayState parameter in IDP-init-SSO SAML flows is the URL that you want to send the user to after successful validation of the SAML assertion at the SP. That would work for the vast majority of SAML deployments out there.
However, that mechanism indeed does not protect against CSRF attacks this is why the spec is silent on the value of RelayState in IDP-init-SSO and leaves it open to agree on mechanisms between IDP and SP to prevent CSRF through the value of that parameter. One such mechanism would be to use a signed value in the RelayState but as said, nothing is standardized and it would thus depend on a bi-lateral agreement between IDP and SP which does not scale.
In summary: send the value of the URL that you want the user to go to as the RelayState value in the "unsolicited" SAML Response that you send to the SP. How you get the IDP's SAML stack to do that is implementation specific. For Auth0 you can read on this at: https://auth0.com/docs/protocols/saml/saml-configuration#idp-initiated-sso, and in your case it would look like:
https://{accountname}.auth0.com/samlp/YOUR_CLIENT_ID?RelayState=http://FINAL_DESTINATION_URL
If a SAML IdP has a preconfigured ACS URL (e.g., one that comes from SP metadata), should it ignore the one sent in an AuthNRequest?
The SAML Core spec states that the IdP must use the ACS specified in the AuthnRequest. It also states that the IdP must in some way ensure that the ACS belongs to the SP. For example by relying on message signature or that the ACS is one defined in the metadata.
From the spec
AssertionConsumerServiceURL [Optional]
Specifies by value the location to which the message MUST be returned to the
requester. The responder MUST ensure by some means that the value specified is in fact associated
with the requester. [SAMLMeta] provides one possible mechanism; signing the enclosing
message is another.
In the case of IDP Initiated FLow, Is the AuthnStatement is also mandatory in Assertion of the SAML Response?
Edit:
And what is bearer Assertion and what is its use?
As far as we are talking about the Authentication Request Protocol which is used in Web Browser SSO Profile for both SP and IDP initialized single sign-on, the standard has the followng to say:
In case profile doesn't override) The assertion(s)
returned MUST contain a element that represents the
presenter. The identifier type and format are determined by the
identity provider. At least one statement in at least one assertion
MUST be a that describes the authentication
performed by the responder or authentication service associated with
it. (2250-2253 core)
and
The set of one or more assertions MUST contain at least one
that reflects the authentication of the principal to
the identity provider. (547-548 profiles)
So the answer is - depends on profile, some SAML profiles (including custom ones) may not require AuthnStatements, but the most typical SAML profile for web single sign-on (and the one you are most likely talking about) does require it for both SP and IDP initialized flow.
And to your second question - bearer assertion is such assertion which is using bearer subject confirmation.
Subject confirmation is piece of information which helps recipient of the assertion (relying party / service provider) verify that the presenter of the assertion (attesting party - e.g. browser, or API client, ...) is associated with its subject (about whom was the assertion issued) and authorized to present the assertion on subject's behalf (to make sure that someone cannot use assertion issued for someone else, without someone else's permission). The bearer subject confirmation simply means that the presenter of the assertion is the same as the subject.
Few things are mandatory in SAML. Accordning to SAML AuthnStatement is not mandatory in any assertion. This is probably constrained in some way in the software you are using. If it is mandatory for Assertions in SP init flow I would guess it is mandatory in the IDP init flow to