[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [saml-dev] Re: SAML Response Status Codes for User exceeding max permitted attempts
From: Siddhartha
Purkayastha [mailto:kpsiddharth@gmail.com] The specs say - [RSP] Responder is the correct top-level code. Technically,
it is the authentication authority (not the SAML responder) that behaved
correctly by not letting the user log in. The SAML Responder indicates to the SAML Requester that it
cannot satisfy the requester’s AuthnRequest (success would mean returning
an assertion). The Responder indicates this with a top-level urn:…:Responder
status. The Responder indicates that the specific failure was urn:…:AuthnFailed
in the second-level status.
[RSP] sending <StatusMessage>
and/or <StatusDetail> using custom error codes, IMO, is still not desirable
but is certainly way better than sending plain text indicating the
reason. IMO, it is still not desirable since attackers can still possibly
intuit conditions from those codes. For example, if I make several
attempts to login using various passwords and I keep getting back a custom code
of 73492 and on the next try I get back the error 89217, I can deduce that I
was probably using a good user id but I just locked the account due to bad
password attempts. Without this detail, I have no idea whether I’m
even using a valid user id. So, again, providing
too much detail is a security risk. 2009/1/21 <robert.philpott@rsa.com> The proper way to handle this
(IMO) is to set a top-level status code of urn:oasis:names:tc:SAML:2.0:status:Responder And a second-level status code
of urn:oasis:names:tc:SAML:2.0:status:AuthnFailed If additional details need to
be provided, they should be placed into the optional <StatusMessage> or <StatusDetail> elements. Note that it is normally a
significant security risk to provide this much detail about an authentication
request and most IdP implementations shouldn't/won't send it. This falls
in the category of leaking too much information to a potential attacker. Rob Philpott RSA, the Security Division of EMC From: Siddhartha Purkayastha [mailto:kpsiddharth@gmail.com] I went through the 2.0 documentation - and
apparently, there isnt such a status. So my question should probably have been
what would be the best way to inform the requester for such a status ? 2009/1/21 Siddhartha Purkayastha <kpsiddharth@gmail.com> Hello All - |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]