[Esapi-dev] Language-independent description of how ESAPI loginworks

[Mike Boberski]

That approach sounds good to me, thanks. I'll put together some initial
notes for at least authentication for your consideration this week, if not
tomorrow.

Mike


On Sun, Jan 17, 2010 at 9:35 PM, Jeff Williams <
jeff.williams at aspectsecurity.com> wrote:

>  I’m partial to the JSR process used by Java.  Take the Servlet 3.0
> specification for instance. The format is easy to understand and allows for
> SHOULDs and MUSTs as well as discussion and explanation.
>
>
>
> http://jcp.org/aboutJava/communityprocess/final/jsr315/index.html
>
>
>
> I’d like to get started drafting such a thing, as I think it’s an absolute
> prerequisite for any kind of TCK.
>
>
>
> --Jeff
>
>
>
>
>
> *From:* Mike Boberski [mailto:mike.boberski at gmail.com]
> *Sent:* Sunday, January 17, 2010 9:15 PM
> *To:* Jeff Williams
> *Cc:* Craig Younkins; Boberski, Michael [USA]; ESAPI-Developers
> *Subject:* Re: [Esapi-dev] Language-independent description of how ESAPI
> loginworks
>
>
>
> Can you help me with an example of something along the lines as you
> suggest?
>
> Mike
>
>  On Sun, Jan 17, 2010 at 9:14 PM, Jeff Williams <
> jeff.williams at aspectsecurity.com> wrote:
>
> Mike,
>
>
>
> I’d prefer to capture the language-independent requirements for the ESAPI
> methods in some form of spec. I feel that the sequence diagram format
> implies too much about the implementation.
>
>
>
> --Jeff
>
>
>
>
>
> *From:* esapi-dev-bounces at lists.owasp.org [mailto:
> esapi-dev-bounces at lists.owasp.org] *On Behalf Of *Craig Younkins
> *Sent:* Sunday, January 17, 2010 3:55 PM
> *To:* Boberski, Michael [USA]
> *Cc:* ESAPI-Developers
> *Subject:* Re: [Esapi-dev] Language-independent description of how ESAPI
> loginworks
>
>
>
> "1. Client requests page, server sends HTTP authentication required
> response according to the ESAPI authentication adapter"
>
>
> I'm not sure if you meant HTTP authentication required (code 401 -
> Unauthorized). My understanding is that this is only used for basic digest
> authentication and instructs the browser to show a pop-up dialog to enter
> credentials. The credentials are base64 encoded and sent with every
> subsequent request. Also, there is no way to log out. For these reasons,
> basic authentication is not very secure.
>
> It believe the Authenticator provides the functionality to verify user
> credentials and add a User object to the session, but does not indicate a
> particular method of authentication. It's the dev's job to create an
> Authentication implementation which does what they want in login(). The
> FileBasedAuthenticaton reference implementation obtains the username and
> password from 2 POST params whose names are set in the configuration.
>
> Hope this helps!
>
>
>
> --
>
> Craig Younkins
>
>
>
> On Fri, Jan 15, 2010 at 4:29 PM, Boberski, Michael [USA] <
> boberski_michael at bah.com> wrote:
>
> Hi,
>
>
>
> I'm trying to come up with a programming-language independent description
> of how login works, in terms of a control flow. After I do this, I'll
> repeat, for logout. All of this will then be published and posted at some
> point.
>
>
>
> Towards that end... How close am I with the table below; please explain
> where I'm not getting it or have made an error, if you're able to take a few
> minutes to review it.
>
>
>
> Best,
>
>
>
> Mike B.
>
>
>
> *App Server*
>
> *Browser*
>
> *ESAPI Authenticator*
>
> *ESAPI User*
>
> 1. Client requests page, server sends HTTP authentication required response
> according to the ESAPI authentication adapter (i.e. the combined ESAPI User
> and Authenticator interface implementations).
>
> <==
>
> This is an ESAPI authentication adapter integration point, code that
> prompts for a given authentication method.
>
>
>
> 2. Browser receives request, user enters user name and authentication data,
> browser sends data.
>
>
>
> ==>
>
> This is a language-specific integration point, retrieving the information
> is done differently depending on programming language.
>
> 3. ESAPI gets the user name and credentials from the user’s session.
>
>
>
> ==>
>
> This is one of two ESAPI authentication adapter integration points, to
> perform the actual authentication e.g. check a password, a directory, a
> certificate, and so on.
>
> ==>
>
> There is support for remember tokens, but information about this is not
> described here for clarity.
>
> 4. ESAPI attempts to authenticate the user using the authentication method
> implemented by the adapter.
>
>
>
> ==>
>
> This works the same way for all programming language versions of ESAPI that
> support ESAPI authentication adapters
>
> 5. ESAPI creates an ESAPI user object if authentication is successful,
> throws exception and processing stops if fails.
>
> ==>
>
> This is the second ESAPI authentication adapter integration points, if you
> are integrating an existing authentication wrapper into ESAPI, starting with
> the third security check listed here.
>
> ==>
>
> This works the same way for all programming language versions of ESAPI that
> support ESAPI authentication adapters; this is where application and/or
> organization-specific (or more simply “best practices” according to e.g.
> ASVS) checks are made, besides whether or not the user has valid
> credentials.
>
> 6. ESAPI  performs the following additional security checks:
>
> ·         Check authentication request was a HTTP POST
>
> ·         Check authentication was over SSL
>
> ·         Check to see if this user is anonomous according to the ESAPI
> adapter user data store
>
> ·         Check to see if this user account was disabled according to the
> ESAPI adapter user data store
>
> ·         Check to see if this user account was locked according to the
> ESAPI adapter user data store
>
> ·         Check to see if this user account was expired according to the
> ESAPI adapter user data store
>
> ·         Check to see if this user’s session was timed out due to
> inactivity according to the ESAPI adapter user data store
>
> ·         Check to see if this user’s session was timed out using an
> absolute timeout according to the ESAPI adapter user data store
>
> ESAPI throws an exception and processing stops if any one of the above
> checks fail.
>
>
>
> ==>
>
> This is a language-specific integration point, creating the session is done
> differently depending on programming language.
>
> 7. ESAPI creates a new HTTP session for the user.
>
>
>
> ==>
>
> This is a language-specific integration point, managing sessions is done
> differently depending on programming language.
>
> 8. ESAPI creates a new HTTP session, sets the value of the authenticated
> ESAPI user object’s session attribute to the newly created session, then
> does the reverse (adds a new user attribute to the newly created session and
> sets it to the value of the ESAPI user object), then resets the current
> thread to the new thread.
>
>
>
>
> _______________________________________________
> Esapi-dev mailing list
> Esapi-dev at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-dev
>
>
>
>
> _______________________________________________
> Esapi-dev mailing list
> Esapi-dev at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-dev/attachments/20100117/eef48784/attachment-0001.html