<commit_before><?xml version="1.0" encoding="UTF-8"?>
<?oxygen RNGSchema="http://www.oasis-open.org/docbook/xml/5.0/rng/docbook.rng" type="xml"?>
<article class="faq" xml:id="spring-security-faq" xmlns="http://docbook.org/ns/docbook"
    xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0">
    <info>
        <title>Frequently Answered Questions (FAQ)</title>
    </info>
    <section>
        <title>General Questions</title>
        <qandaset>
            <qandadiv>
                <qandaentry xml:id="faq-other-concerns">
                    <question>
                        <para>Will Spring Security take care of all my application security
                            requirements?</para>
                    </question>
                    <answer>
                        <para> Spring Security provides you with a very flexible framework for your
                            authentication and authorization requirements, but there are many other
                            considerations for building a secure application that are outside its
                            scope. Web applications are vulnerable to all kinds of attacks which you
                            should be familiar with, preferably before you start development so you
                            can design and code with them in mind from the beginning. Check out the
                            <link xlink:href="http://www.owasp.org/">OWASP web site</link> for
                            information on the major issues facing web application developers and
                            the countermeasures you can use against them.</para>
                    </answer>
                </qandaentry>
                <qandaentry xml:id="faq-web-xml">
                    <question>
                        <para>Why not just use web.xml security?</para>
                    </question>
                    <answer>
                        <para>Let's assume you're developing an enterprise application based on
                            Spring. There are four security concerns you typically need to address:
                            authentication, web request security, service layer security (i.e. your
                            methods that implement business logic), and domain object instance
                            security (i.e. different domain objects have different permissions).
                            With these typical requirements in mind: <orderedlist>
                            <listitem>
                                <para><emphasis>Authentication</emphasis>: The servlet specification
                                    provides an approach to authentication. However, you will need
                                    to configure the container to perform authentication which
                                    typically requires editing of container-specific "realm"
                                    settings. This makes a non-portable configuration, and if you
                                    need to write an actual Java class to implement the container's
                                    authentication interface, it becomes even more non-portable.
                                    With Spring Security you achieve complete portability - right
                                    down to the WAR level. Also, Spring Security offers a choice of
                                    production-proven authentication providers and mechanisms,
                                    meaning you can switch your authentication approaches at
                                    deployment time. This is particularly valuable for software
                                    vendors writing products that need to work in an unknown target
                                    environment.</para>
                            </listitem>
                            <listitem>
                                <para><emphasis>Web request security:</emphasis> The servlet
                                    specification provides an approach to secure your request URIs.
                                    However, these URIs can only be expressed in the servlet
                                    specification's own limited URI path format. Spring Security
                                    provides a far more comprehensive approach. For instance, you
                                    can use Ant paths or regular expressions, you can consider parts
                                    of the URI other than simply the requested page (e.g. you can
                                    consider HTTP GET parameters) and you can implement your own
                                    runtime source of configuration data. This means your web
                                    request security can be dynamically changed during the actual
                                    execution of your webapp.</para>
                            </listitem>
                            <listitem>
                                <para><emphasis>Service layer and domain object security:</emphasis>
                                    The absence of support in the servlet specification for services
                                    layer security or domain object instance security represent
                                    serious limitations for multi-tiered applications. Typically
                                    developers either ignore these requirements, or implement
                                    security logic within their MVC controller code (or even worse,
                                    inside the views). There are serious disadvantages with this
                                    approach: <orderedlist>
                                    <listitem>
                                        <para><emphasis>Separation of concerns:</emphasis>
                                            Authorization is a crosscutting concern and should be
                                            implemented as such. MVC controllers or views
                                            implementing authorization code makes it more difficult
                                            to test both the controller and authorization logic,
                                            more difficult to debug, and will often lead to code
                                            duplication.</para>
                                    </listitem>
                                    <listitem>
                                        <para><emphasis>Support for rich clients and web
                                            services:</emphasis> If an additional client type must
                                            ultimately be supported, any authorization code embedded
                                            within the web layer is non-reusable. It should be
                                            considered that Spring remoting exporters only export
                                            service layer beans (not MVC controllers). As such
                                            authorization logic needs to be located in the services
                                            layer to support a multitude of client types.</para>
                                    </listitem>
                                    <listitem>
                                        <para><emphasis>Layering issues:</emphasis> An MVC
                                            controller or view is simply the incorrect architectural
                                            layer to implement authorization decisions concerning
                                            services layer methods or domain object instances.
                                            Whilst the Principal may be passed to the services layer
                                            to enable it to make the authorization decision, doing
                                            so would introduce an additional argument on every
                                            services layer method. A more elegant approach is to use
                                            a ThreadLocal to hold the Principal, although this would
                                            likely increase development time to a point where it
                                            would become more economical (on a cost-benefit basis)
                                            to simply use a dedicated security framework.</para>
                                    </listitem>
                                    <listitem>
                                        <para><emphasis>Authorisation code quality:</emphasis> It is
                                            often said of web frameworks that they "make it easier
                                            to do the right things, and harder to do the wrong
                                            things". Security frameworks are the same, because they
                                            are designed in an abstract manner for a wide range of
                                            purposes. Writing your own authorization code from
                                            scratch does not provide the "design check" a framework
                                            would offer, and in-house authorization code will
                                            typically lack the improvements that emerge from
                                            widespread deployment, peer review and new versions.
                                        </para>
                                    </listitem>
                                    </orderedlist></para>
                            </listitem>
                            </orderedlist></para>
                        <para> For simple applications, servlet specification security may just be
                            enough. Although when considered within the context of web container
                            portability, configuration requirements, limited web request security
                            flexibility, and non-existent services layer and domain object instance
                            security, it becomes clear why developers often look to alternative
                            solutions. </para>
                    </answer>
                </qandaentry>
                <qandaentry xml:id="faq-requirements">
                    <question>
                        <para>What Java and Spring Framework versions are required?</para>
                    </question>
                    <answer>
                        <para> Spring Security 2.0.x requires a minimum JDK version of 1.4 and is
                            built against Spring 2.0.x. It should also be compatible with
                            applications using Spring 2.5.x. </para>
                        <para> Spring Security 3.0 requires JDK 1.5 as a minimum and will also
                            require Spring 3.0. </para>
                    </answer>
                </qandaentry>
                <qandaentry xml:id="faq-start-simple">
                    <question>
                        <para> I'm new to Spring Security and I need to build an application that
                            supports CAS single sign-on over HTTPS, while allowing Basic
                            authentication locally for certain URLs, authenticating against multiple
                            back end user information sources (LDAP and JDBC). I've copied some
                            configuration files I found but it doesn't work. What could be wrong? </para>
                        <para>Or subsititute an alternative complex scenario...</para>
                    </question>
                    <answer>
                        <para> Realistically, you need an understanding of the technolgies you are
                            intending to use before you can successfully build applications with
                            them. Security is complicated. Setting up a simple configuration using a
                            login form and some hard-coded users using Spring Security's namespace
                            is reasonably straightforward. Moving to using a backed JDBC database is
                            also easy enough. But if you try and jump straight to a complicated
                            deployment scenario like this you will almost certainly be frustrated.
                            There is a big jump in the learning curve required to set up systems<commit_msg>Minor FAQ update on version info.<commit_after><?xml version="1.0" encoding="UTF-8"?>
<?oxygen RNGSchema="http://www.oasis-open.org/docbook/xml/5.0/rng/docbook.rng" type="xml"?>
<article class="faq" xml:id="spring-security-faq" xmlns="http://docbook.org/ns/docbook"
    xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0">
    <info>
        <title>Frequently Answered Questions (FAQ)</title>
    </info>
    <section>
        <title>General Questions</title>
        <qandaset>
            <qandadiv>
                <qandaentry xml:id="faq-other-concerns">
                    <question>
                        <para>Will Spring Security take care of all my application security
                            requirements?</para>
                    </question>
                    <answer>
                        <para> Spring Security provides you with a very flexible framework for your
                            authentication and authorization requirements, but there are many other
                            considerations for building a secure application that are outside its
                            scope. Web applications are vulnerable to all kinds of attacks which you
                            should be familiar with, preferably before you start development so you
                            can design and code with them in mind from the beginning. Check out the
                            <link xlink:href="http://www.owasp.org/">OWASP web site</link> for
                            information on the major issues facing web application developers and
                            the countermeasures you can use against them.</para>
                    </answer>
                </qandaentry>
                <qandaentry xml:id="faq-web-xml">
                    <question>
                        <para>Why not just use web.xml security?</para>
                    </question>
                    <answer>
                        <para>Let's assume you're developing an enterprise application based on
                            Spring. There are four security concerns you typically need to address:
                            authentication, web request security, service layer security (i.e. your
                            methods that implement business logic), and domain object instance
                            security (i.e. different domain objects have different permissions).
                            With these typical requirements in mind: <orderedlist>
                            <listitem>
                                <para><emphasis>Authentication</emphasis>: The servlet specification
                                    provides an approach to authentication. However, you will need
                                    to configure the container to perform authentication which
                                    typically requires editing of container-specific "realm"
                                    settings. This makes a non-portable configuration, and if you
                                    need to write an actual Java class to implement the container's
                                    authentication interface, it becomes even more non-portable.
                                    With Spring Security you achieve complete portability - right
                                    down to the WAR level. Also, Spring Security offers a choice of
                                    production-proven authentication providers and mechanisms,
                                    meaning you can switch your authentication approaches at
                                    deployment time. This is particularly valuable for software
                                    vendors writing products that need to work in an unknown target
                                    environment.</para>
                            </listitem>
                            <listitem>
                                <para><emphasis>Web request security:</emphasis> The servlet
                                    specification provides an approach to secure your request URIs.
                                    However, these URIs can only be expressed in the servlet
                                    specification's own limited URI path format. Spring Security
                                    provides a far more comprehensive approach. For instance, you
                                    can use Ant paths or regular expressions, you can consider parts
                                    of the URI other than simply the requested page (e.g. you can
                                    consider HTTP GET parameters) and you can implement your own
                                    runtime source of configuration data. This means your web
                                    request security can be dynamically changed during the actual
                                    execution of your webapp.</para>
                            </listitem>
                            <listitem>
                                <para><emphasis>Service layer and domain object security:</emphasis>
                                    The absence of support in the servlet specification for services
                                    layer security or domain object instance security represent
                                    serious limitations for multi-tiered applications. Typically
                                    developers either ignore these requirements, or implement
                                    security logic within their MVC controller code (or even worse,
                                    inside the views). There are serious disadvantages with this
                                    approach: <orderedlist>
                                    <listitem>
                                        <para><emphasis>Separation of concerns:</emphasis>
                                            Authorization is a crosscutting concern and should be
                                            implemented as such. MVC controllers or views
                                            implementing authorization code makes it more difficult
                                            to test both the controller and authorization logic,
                                            more difficult to debug, and will often lead to code
                                            duplication.</para>
                                    </listitem>
                                    <listitem>
                                        <para><emphasis>Support for rich clients and web
                                            services:</emphasis> If an additional client type must
                                            ultimately be supported, any authorization code embedded
                                            within the web layer is non-reusable. It should be
                                            considered that Spring remoting exporters only export
                                            service layer beans (not MVC controllers). As such
                                            authorization logic needs to be located in the services
                                            layer to support a multitude of client types.</para>
                                    </listitem>
                                    <listitem>
                                        <para><emphasis>Layering issues:</emphasis> An MVC
                                            controller or view is simply the incorrect architectural
                                            layer to implement authorization decisions concerning
                                            services layer methods or domain object instances.
                                            Whilst the Principal may be passed to the services layer
                                            to enable it to make the authorization decision, doing
                                            so would introduce an additional argument on every
                                            services layer method. A more elegant approach is to use
                                            a ThreadLocal to hold the Principal, although this would
                                            likely increase development time to a point where it
                                            would become more economical (on a cost-benefit basis)
                                            to simply use a dedicated security framework.</para>
                                    </listitem>
                                    <listitem>
                                        <para><emphasis>Authorisation code quality:</emphasis> It is
                                            often said of web frameworks that they "make it easier
                                            to do the right things, and harder to do the wrong
                                            things". Security frameworks are the same, because they
                                            are designed in an abstract manner for a wide range of
                                            purposes. Writing your own authorization code from
                                            scratch does not provide the "design check" a framework
                                            would offer, and in-house authorization code will
                                            typically lack the improvements that emerge from
                                            widespread deployment, peer review and new versions.
                                        </para>
                                    </listitem>
                                    </orderedlist></para>
                            </listitem>
                            </orderedlist></para>
                        <para> For simple applications, servlet specification security may just be
                            enough. Although when considered within the context of web container
                            portability, configuration requirements, limited web request security
                            flexibility, and non-existent services layer and domain object instance
                            security, it becomes clear why developers often look to alternative
                            solutions. </para>
                    </answer>
                </qandaentry>
                <qandaentry xml:id="faq-requirements">
                    <question>
                        <para>What Java and Spring Framework versions are required?</para>
                    </question>
                    <answer>
                        <para> Spring Security 3.0 and 3.1 require at least JDK 1.5 and also
                            require Spring 3.0.3 as a minimum. Ideally you should be using the latest
                            release versions to avoid problems.
                        </para>
                        <para> Spring Security 2.0.x requires a minimum JDK version of 1.4 and is
                            built against Spring 2.0.x. It should also be compatible with
                            applications using Spring 2.5.x. </para>
                    </answer>
                </qandaentry>
                <qandaentry xml:id="faq-start-simple">
                    <question>
                        <para> I'm new to Spring Security and I need to build an application that
                            supports CAS single sign-on over HTTPS, while allowing Basic
                            authentication locally for certain URLs, authenticating against multiple
                            back end user information sources (LDAP and JDBC). I've copied some
                            configuration files I found but it doesn't work. What could be wrong? </para>
                        <para>Or subsititute an alternative complex scenario...</para>
                    </question>
                    <answer>
                        <para> Realistically, you need an understanding of the technolgies you are
                            intending to use before you can successfully build applications with
                            them. Security is complicated. Setting up a simple configuration using a
                            login form and some hard-coded users using Spring Security's namespace
                            is reasonably straightforward. Moving to using a backed JDBC database is
                            also easy enough. But if you try and jump straight to a complicated
                            deployment scenario like this you will almost certainly be frustrated.
                            There is a big jump in the learning curve required to set up systems
{'fraction_non_alphanumeric': 0.03929211818819677, 'fraction_numerical': 0.0021439151789194666, 'mean_word_length': 1.0624648283624085, 'pattern_counts': {'":': 0, '<': 209, '<?xml version=': 2, '>': 209, 'https://': 0, 'lorem ipsum': 0, 'www.': 6, 'xml': 24}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 226, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6787224', 'n_tokens_mistral': 4398, 'n_tokens_neox': 4105, 'n_words': 2061}