[jboss-cvs] JBossAS SVN: r100953 - in projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US: extras and 1 other directory.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Mon Feb 15 02:27:32 EST 2010
Author: jaredmorgs
Date: 2010-02-15 02:27:32 -0500 (Mon, 15 Feb 2010)
New Revision: 100953
Added:
projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/
projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/authorization-policy-specific-security-domain-1.xml_sample
projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/authorization-policy-specific-security-domain-2.xml_sample
projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/jboss-beans.xml_sample
projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/security-policies-EJBJACCPolicyModuleDelegate.java
projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/security-policies-WebJACCPolicyModuleDelegate.java
projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/security-policies-authorization_delegate_example.java
projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/security-policies-authorization_delegate_example.java~
projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/security-policies-jboss-beans_all_ejb_war.xml_sample
projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/security-policies-jboss-beans_default.xml_sample
Modified:
projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/chap-Security_Configuration_And_Architecture.xml
Log:
Updated Security Chapter with Pluggable access control blog post from http://anil-identity.blogspot.com/2008/12/as5-pluggable-access-control-ejbweb.html
Modified: projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/chap-Security_Configuration_And_Architecture.xml
===================================================================
--- projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/chap-Security_Configuration_And_Architecture.xml 2010-02-15 06:35:28 UTC (rev 100952)
+++ projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/chap-Security_Configuration_And_Architecture.xml 2010-02-15 07:27:32 UTC (rev 100953)
@@ -634,33 +634,29 @@
</para>
<itemizedlist>
<listitem>
- <para>
- <emphasis role="bold">AuthenticationManager</emphasis>: This interface is responsible for validating credentials associated with principals. Principals are identities, such as usernames, employee numbers, and social security numbers. Credentials are proof of the identity, such as passwords, session keys, and digital signatures. The <literal>isValid</literal> method is invoked to determine whether a user identity and associated credentials as known in the operational environment are valid proof of the user's identity.
+ <para><classname>AuthenticationManager</classname>: This interface is responsible for validating credentials associated with principals. Principals are identities, such as usernames, employee numbers, and social security numbers. Credentials are proof of the identity, such as passwords, session keys, and digital signatures. The <literal>isValid</literal> method is invoked to determine whether a user identity and associated credentials as known in the operational environment are valid proof of the user's identity.
</para>
</listitem>
<listitem>
- <para>
- <emphasis role="bold">RealmMapping</emphasis>: This interface is responsible for principal mapping and role mapping. The <literal>getPrincipal</literal> method takes a user identity as known in the operational environment and returns the application domain identity. The <literal>doesUserHaveRole</literal> method validates that the user identity in the operation environment has been assigned the indicated role from the application domain.
+ <para><classname>RealmMapping</classname>: This interface is responsible for principal mapping and role mapping. The <literal>getPrincipal</literal> method takes a user identity as known in the operational environment and returns the application domain identity. The <literal>doesUserHaveRole</literal> method validates that the user identity in the operation environment has been assigned the indicated role from the application domain.
</para>
</listitem>
<listitem>
- <para>
- <emphasis role="bold">SecurityProxy</emphasis>: This interface describes the requirements for a custom <literal>SecurityProxyInterceptor</literal> plugin. A <literal>SecurityProxy</literal> allows for the externalization of custom security checks on a per-method basis for both the EJB home and remote interface methods.
+ <para><classname>SecurityProxy</classname>: This interface describes the requirements for a custom <literal>SecurityProxyInterceptor</literal> plugin. A <literal>SecurityProxy</literal> allows for the externalization of custom security checks on a per-method basis for both the EJB home and remote interface methods.
</para>
</listitem>
<listitem>
- <para>
- <emphasis role="bold">SubjectSecurityManager</emphasis>: This is a subinterface of <literal>AuthenticationManager</literal> that adds accessor methods for obtaining the security domain name of the security manager and the current thread's authenticated <literal>Subject</literal>.
+ <para><classname>SubjectSecurityManager</classname>: This is a subinterface of <literal>AuthenticationManager</literal> that adds accessor methods for obtaining the security domain name of the security manager and the current thread's authenticated <literal>Subject</literal>.
</para>
</listitem>
<listitem>
- <para>
- <emphasis role="bold">SecurityDomain</emphasis>: This is an extension of the <literal>AuthenticationManager</literal>, <literal>RealmMapping</literal>, and <literal>SubjectSecurityManager</literal> interfaces. It is a move to a comprehensive security interface based on the JAAS Subject, a <literal>java.security.KeyStore</literal>, and the JSSE <literal>com.sun.net.ssl.KeyManagerFactory</literal> and <literal>com.sun.net.ssl.TrustManagerFactory</literal> interfaces. This interface is a work in progress that will be the basis of a multi-domain security architecture that will better support ASP style deployments of applications and resources.
+ <para><classname>SecurityDomain</classname>: This is an extension of the <literal>AuthenticationManager</literal>, <literal>RealmMapping</literal>, and <literal>SubjectSecurityManager</literal> interfaces. <classname>SecurityDomain</classname> is the recommended way to implement security in components, because of the advantages the JAAS Subject offers, and the increased support offered to to ASP-style application and resource deployments. A <literal>java.security.KeyStore</literal>, and the JSSE <literal>com.sun.net.ssl.KeyManagerFactory</literal> and <literal>com.sun.net.ssl.TrustManagerFactory</literal> interfaces are included in the class.
</para>
</listitem>
</itemizedlist>
<para>
- Note that the <literal>AuthenticationManager</literal>, <literal>RealmMapping</literal> and <literal>SecurityProxy</literal> interfaces have no association to JAAS related classes. Although the JBossSX framework is heavily dependent on JAAS, the basic security interfaces required for implementation of the J2EE security model are not. The JBossSX framework is simply an implementation of the basic security plug-in interfaces that are based on JAAS. The component diagram presented in <xref linkend="The_JBoss_Security_Model-The_relationship_between_the_JBossSX_framework_implementation_classes_and_the_JBoss_server_EJB_container_layer."/> illustrates this fact. The implication of this plug-in architecture is that you are free to replace the JAAS-based JBossSX implementation classes with your own custom security manager implementation that does not make use of JAAS, if you so desire. You'll see how to do this when you look at the JBossSX MBeans available for the configurat!
ion of JBossSX in <xref linkend="The_JBoss_Security_Model-The_relationship_between_the_JBossSX_framework_implementation_classes_and_the_JBoss_server_EJB_container_layer."/>.
+ Note that the <literal>AuthenticationManager</literal>, <literal>RealmMapping</literal> and <literal>SecurityProxy</literal> interfaces have no association to JAAS related classes. Although the JBossSX framework is heavily dependent on JAAS, the basic security interfaces required for implementation of the J2EE security model are not. The JBossSX framework is simply an implementation of the basic security plug-in interfaces that are based on JAAS. </para>
+ <para>The component diagram presented in <xref linkend="The_JBoss_Security_Model-The_relationship_between_the_JBossSX_framework_implementation_classes_and_the_JBoss_server_EJB_container_layer."/> illustrates this fact. The implication of this plug-in architecture is that you are free to replace the JAAS-based JBossSX implementation classes with your own custom security manager implementation that does not make use of JAAS, if you so desire. You'll see how to do this when you look at the JBossSX MBeans available for the configuration of JBossSX in <xref linkend="The_JBoss_Security_Model-The_relationship_between_the_JBossSX_framework_implementation_classes_and_the_JBoss_server_EJB_container_layer."/>.
</para>
<figure id="The_JBoss_Security_Model-The_relationship_between_the_JBossSX_framework_implementation_classes_and_the_JBoss_server_EJB_container_layer.">
<title>The relationship between the JBossSX framework implementation classes and the JBoss server EJB container layer.</title>
@@ -683,17 +679,13 @@
</imageobject>
</mediaobject>
</figure>
- <para>
- The value of a <literal>security-domain</literal> element specifies the JNDI name of the security manager interface implementation that JBoss uses for the EJB and web containers. This is an object that implements both of the <literal>AuthenticationManager</literal> and <literal>RealmMapping</literal> interfaces. When specified as a top-level element it defines what security domain in effect for all EJBs in the deployment unit. This is the typical usage because mixing security managers within a deployment unit complicates inter-component operation and administration.
+ <para>The value of a <literal>security-domain</literal> element specifies the JNDI name of the security manager interface implementation that JBoss uses for the EJB and web containers. This is an object that implements both of the <literal>AuthenticationManager</literal> and <literal>RealmMapping</literal> interfaces. When specified as a top-level element it defines what security domain in effect for all EJBs in the deployment unit. This is the typical usage because mixing security managers within a deployment unit complicates inter-component operation and administration.
</para>
- <para>
- To specify the security domain for an individual EJB, you specify the <literal>security-domain</literal> at the container configuration level. This will override any top-level security-domain element.
+ <para>To specify the security domain for an individual EJB, you specify the <literal>security-domain</literal> at the container configuration level. This will override any top-level security-domain element.
</para>
- <para>
- The <literal>unauthenticated-principal</literal> element specifies the name to use for the <literal>Principal</literal> object returned by the <literal>EJBContext.getUserPrincipal</literal> method when an unauthenticated user invokes an EJB. Note that this conveys no special permissions to an unauthenticated caller. Its primary purpose is to allow unsecured servlets and JSP pages to invoke unsecured EJBs and allow the target EJB to obtain a non-null <literal>Principal</literal> for the caller using the <literal>getUserPrincipal</literal> method. This is a J2EE specification requirement.
+ <para>The <literal>unauthenticated-principal</literal> element specifies the name to use for the <literal>Principal</literal> object returned by the <literal>EJBContext.getUserPrincipal</literal> method when an unauthenticated user invokes an EJB. Note that this conveys no special permissions to an unauthenticated caller. Its primary purpose is to allow unsecured servlets and JSP pages to invoke unsecured EJBs and allow the target EJB to obtain a non-null <literal>Principal</literal> for the caller using the <literal>getUserPrincipal</literal> method. This is a J2EE specification requirement.
</para>
- <para>
- The <literal>security-proxy</literal> element identifies a custom security proxy implementation that allows per-request security checks outside the scope of the EJB declarative security model without embedding security logic into the EJB implementation. This may be an implementation of the <literal>org.jboss.security.SecurityProxy</literal> interface, or just an object that implements methods in the home, remote, local home or local interfaces of the EJB to secure without implementing any common interface. If the given class does not implement the <literal>SecurityProxy</literal> interface, the instance must be wrapped in a <literal>SecurityProxy</literal> implementation that delegates the method invocations to the object. The <literal>org.jboss.security.SubjectSecurityProxy</literal> is an example <literal>SecurityProxy</literal> implementation used by the default JBossSX installation.
+ <para>The <literal>security-proxy</literal> element identifies a custom security proxy implementation that allows per-request security checks outside the scope of the EJB declarative security model without embedding security logic into the EJB implementation. This may be an implementation of the <literal>org.jboss.security.SecurityProxy</literal> interface, or just an object that implements methods in the home, remote, local home or local interfaces of the EJB to secure without implementing any common interface. If the given class does not implement the <literal>SecurityProxy</literal> interface, the instance must be wrapped in a <literal>SecurityProxy</literal> implementation that delegates the method invocations to the object. The <literal>org.jboss.security.SubjectSecurityProxy</literal> is an example <literal>SecurityProxy</literal> implementation used by the default JBossSX installation.
</para>
<para>
Take a look at a simple example of a custom <literal>SecurityProxy</literal> in the context of a trivial stateless session bean. The custom <literal>SecurityProxy</literal> validates that no one invokes the bean's <literal>echo</literal> method with a four-letter word as its argument. This is a check that is not possible with role-based security; you cannot define a <literal>FourLetterEchoInvoker</literal> role because the security context is the method argument, not a property of the caller. The code for the custom <literal>SecurityProxy</literal> is given in <xref linkend="Enabling_Declarative_Security_in_JBoss_Revisited-The_example_1_custom_EchoSecurityProxy_implementation_that_enforces_the_echo_argument_based_security_constraint."/>, and the full source code is available in the <literal>src/main/org/jboss/book/security/ex1</literal> directory of the book examples.
@@ -1105,43 +1097,6 @@
</itemizedlist>
</section>
</section>
- <section>
- <title>Configuring Microcontainer Security Domains</title>
- <para>Historically, the Enterprise Application Platform used the static <filename>login-config.xml</filename> file to configure the security domain. Extra functionality was provided with the introduction of the DynamicLoginConfig security service. This functionality allowed you to specify a Java Authentication and Authorisation Service (JAAS) as part of an application deployment, rather than having to include the configuration information in <filename>login-config.xml</filename>.</para>
- <para>The Enterprise Application Platform now provides these security requirements through the use of the JBoss Microcontainer and EJBs. </para>
- <para>In a security-conscious system, JavaEE components such as Web or Enterprise Java Bean (EJB) components require a Security Domain to manage the authentication, authorization, auditing, and mapping functionality. </para>
- <para>The latest security implementation allows you to create a logically-named deployment descriptor file and specify the security domains within the file. The deployment descriptor can be deployed directly in the deploy folder, or packaged as part of the application JAR or WAR file.</para>
- <procedure>
- <title>Security Domain Deployment Descriptor</title>
- <para>Follow this procedure to configure a security domain deployment descriptor with two domains named web-test and ejb-test.</para>
- <step>
- <title>Create deployment descriptor</title>
- <para>You must create a deployment descriptor file to contain the security domain configuration.</para>
- <para>The filename takes the format <filename><replaceable>[domain_name]</replaceable>-jboss-beans.xml</filename>. The <replaceable>domain_name</replaceable> is arbitrary, however you should choose a name that is meaningful to the application. </para>
- <para>The file must contain the standard XML declaration, and a correctly configured <sgmltag><deployment></sgmltag> element.</para>
- <programlisting role="XML" language="XML"><?xml version="1.0" encoding="UTF-8"?>
-
-<deployment xmlns="urn:jboss:bean-deployer:2.0">
-
-
-</deployment></programlisting>
- </step>
- <step>
- <title>Define application policies</title>
- <para>Within the <sgmltag><deployment></sgmltag> element, the individual application policies are defined. Each policy specifies the login module to use, and any required options. </para>
- <para>In the example below, two application policies are specified. Each policy uses the same login module, and module parameters.</para>
- <programlisting language="XML" lang="XML"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="extras/jboss-beans.xml_sample" parse="text"/></programlisting>
- </step>
- <step>
- <title>Deploy or package the deployment descriptor</title>
- <para>Move the deployment descriptor file to the deploy directory of your installation. </para>
- <para>Alternatively, package the deployment descriptor in the <filename>META-INF</filename> directory of the EJB Jar, or the Web application (WAR).</para>
- </step>
- </procedure>
-<!--TODO: Thought I should mention this here, but technically the link provided in the Note links forward, instead of backwards. I wanted to mention the Login Modules here just in case readers didn't want to go old-school and use the login-config.xml method.--> <note>
- <para>There are other Login Modules available that are shipped with the Enterprise Application Platform. For more information about included login modules, refer to <xref linkend="Defining_Security_Domains-Using_JBoss_Login_Modules"/></para>
- </note>
- </section>
<section id="Security_on_JBoss-Defining_Security_Domains">
<title>Configuring Security Domains</title>
<para>The standard way of configuring security domains for authentication and authorization in JBoss is to use the XML login configuration file. The login configuration policy defines a set of named security domains that each define a stack of login modules that will be called upon to authenticate and authorize users.
@@ -1221,10 +1176,141 @@
<para>
Each login module has its own set of configuration options. These are set as name/value pairs using the <literal>module-option</literal> elements. We'll cover module options in more depth when we look at the individual login modules available in JBoss AS.
</para>
+ <section id="JBoss-Security-Configuring_Microcontainer_Security_Domains">
+ <title>Configuring Microcontainer Security Domains</title>
+<!--Added this section from http://server.dzone.com/articles/security-features-jboss-510--> <para>Historically, the Enterprise Application Platform used the static <filename>login-config.xml</filename> file to configure the security domain. Extra functionality was provided with the introduction of the DynamicLoginConfig security service. This functionality allowed you to specify a Java Authentication and Authorisation Service (JAAS) as part of an application deployment, rather than having to include the configuration information in <filename>login-config.xml</filename>.</para>
+ <para>The Enterprise Application Platform now provides these security requirements through the use of the JBoss Microcontainer and EJBs. </para>
+ <para>In a security-conscious system, JavaEE components such as Web or Enterprise Java Bean (EJB) components require a Security Domain to manage the authentication, authorization, auditing, and mapping functionality. </para>
+ <para>The latest security implementation allows you to create a logically-named deployment descriptor file and specify the security domains within the file. The deployment descriptor can be deployed directly in the deploy folder, or packaged as part of the application JAR or WAR file.</para>
+ <procedure>
+ <title>Security Domain Deployment Descriptor</title>
+ <para>Follow this procedure to configure a security domain deployment descriptor with two domains named web-test and ejb-test.</para>
+ <step>
+ <title>Create deployment descriptor</title>
+ <para>You must create a deployment descriptor file to contain the security domain configuration.</para>
+ <para>The filename takes the format <filename><replaceable>[domain_name]</replaceable>-jboss-beans.xml</filename>. The <replaceable>domain_name</replaceable> is arbitrary, however you should choose a name that is meaningful to the application. </para>
+ <para>The file must contain the standard XML declaration, and a correctly configured <sgmltag><deployment></sgmltag> element.</para>
+ <programlisting role="XML" language="XML"><?xml version="1.0" encoding="UTF-8"?>
+
+<deployment xmlns="urn:jboss:bean-deployer:2.0">
+
+
+</deployment></programlisting>
+ </step>
+ <step>
+ <title>Define application policies</title>
+ <para>Within the <sgmltag><deployment></sgmltag> element, the individual application policies are defined. Each policy specifies the login module to use, and any required options. </para>
+ <para>In the example below, two application policies are specified. Each policy uses the same login module, and module parameters.</para>
+ <note>
+ <para>Other login modules are available for use with the Enterprise Application Platform. For more information about the available login modules, refer to <xref linkend="Defining_Security_Domains-Using_JBoss_Login_Modules"/></para>
+ </note>
+ <programlisting language="XML" lang="XML"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="extras/jboss-beans.xml_sample" parse="text"/></programlisting>
+ </step>
+ <step>
+ <title>Deploy or package the deployment descriptor</title>
+ <para>Move the deployment descriptor file to the <filename>deploy</filename> directory of the required server profile in your installation. </para>
+ <para>Alternatively, package the deployment descriptor in the <filename>META-INF</filename> directory of the EJB Jar, or the Web application (WAR).</para>
+ </step>
+ </procedure>
+<!--TODO: Thought I should mention this here, but technically the link provided in the Note links forward, instead of backwards. I wanted to mention the Login Modules here just in case readers didn't want to go old-school and use the login-config.xml method.--> </section>
+ <section>
+ <title>Configuring Authorization Stacks</title>
+ <para>If a security domain does not define an authorization module, the default <parameter>jboss-web-policy</parameter> and <parameter>jboss-ejb-policy</parameter> authorization configured in <filename>security-policies-jboss-beans.xml</filename> is used. If you specify an JAAS authorization module, or create a custom deployment descriptor file with valid authorization configuration, these settings override the default settings in <filename>security-policies-jboss-beans.xml</filename>. </para>
+ <para>Overriding the default authorization for EJB or Web components is implemented using Java Authorization Contract for Containers (JACC), Extensible Access Control Markup Language (XACML), or custom authorization methods. Configuring this functionality allows access control stacks to be pluggable for a particular component, overriding the default authorization contained in <filename>jboss.xml</filename> (for EJBs) and <filename>jboss-web.xml</filename> (for WAR).</para>
+ <formalpara>
+ <title>Setting authorization for all EJB and WEB components</title>
+ <para>You can override authorization for all EJBs and Web components, or for a particular component.</para>
+ </formalpara>
+ <procedure id="proc-Set_Auth_Policies_For_All_EJB_WAR_Components">
+ <title>Set authorization policies for all EJB and WAR components</title>
+ <para>This procedure describes how to define JACC Authorization control for all EJB and WAR components. The example defines application policy modules for three components: <filename>jboss-web-policy</filename>, <filename>jboss-ejb-policy</filename>, and <filename>jacc-test</filename>.</para>
+ <step>
+ <title>Open the security policy bean</title>
+ <para>Navigate to <filename><replaceable>[install_directory]</replaceable>/jboss-as/server/all/deploy/security</filename></para>
+ <para>Open the <filename>security-policies-jboss-beans.xml</filename> file. </para>
+ <para>By default, the security-policies-jboss-beans.xml file contains the configuration in <xref linkend="exam-security_policies_default_configuration"/></para>
+ <example id="exam-security_policies_default_configuration">
+ <title>security-policies default configuration</title>
+ <programlisting><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="extras/security-policies-jboss-beans_default.xml_sample" parse="text"/></programlisting>
+ </example>
+ </step>
+ <step>
+ <title>Change the application-policy definitions</title>
+ <para>To set a single authorization policy for each component using JACC, amend each <sgmltag><policy-module></sgmltag> <parameter>code</parameter> attribute with the name of the JACC auuthorization module.</para>
+ <programlisting><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="extras/security-policies-jboss-beans_all_ejb_war.xml_sample" parse="text"/></programlisting>
+ </step>
+ <step>
+ <title>Restart server</title>
+ <para>You have now configured the <filename>security-policy-jboss-beans.xml</filename> file with JACC authorization enabled for each application policy.</para>
+ <para>Restart the server to ensure the new security policy takes effect.</para>
+ </step>
+ </procedure>
+ <formalpara>
+ <title>Setting authorization for specific EJB and WEB components</title>
+ <para>If applications require more granular security policies, you can declare multiple authorization security policies for each application policy. New security domains can inherit base settings from another application policy, and override specific settings such as the authorization policy module. </para>
+ </formalpara>
+ <procedure id="proc-Set_Auth_Policies_For_Specific_Domains">
+ <title>Set authorization policies for specific security domains </title>
+ <para>This procedure describes how to inherit settings from other application policy definitions, and specify different authorization policies per security domain. </para>
+ <para>In this procedure, two security domains are defined. The <parameter>test-domain</parameter> security domain uses the UsersRolesLoginModule login module and uses JACC authorization. The <parameter>test-domain-inherited</parameter> security domain inherits the login module information from <parameter>test-domain</parameter>, and specifies XACML authorization must be used.</para>
+ <step>
+ <title>Open the security policy </title>
+ <para>You can specify the security domain settings in the <filename>login-config.xml</filename> file, or create a deployment descriptor file containing the settings. Choose the deployment descriptor if you want to package the security domain settings with your application.</para>
+ <stepalternatives performance="required">
+ <step performance="optional">
+ <title>Locate and open login-config.xml</title>
+ <para>Navigate to the <filename>login-config.xml</filename> file for the server profile you are using and open the file for editing. For example: </para>
+ <para><filename><replaceable>[install_directory]</replaceable>/jboss-as/server/all/conf/login.config.xml</filename></para>
+ </step>
+ <step performance="optional">
+ <title>Create a jboss-beans.xml descriptor</title>
+ <para>Create a <filename><replaceable>[prefix]</replaceable>-jboss-beans.xml</filename> descriptor, replacing <replaceable>[prefix]</replaceable> with a meaningful name (for example, <filename>test-war-jboss-beans.xml</filename>)</para>
+ <para>Save this file in the deploy directory of the server profile you are configuring. For example:</para>
+ <para><filename><replaceable>[install_directory]</replaceable>/jboss-as/server/all/deploy/test-war-jboss-beans.xml</filename></para>
+ </step>
+ </stepalternatives>
+ </step>
+ <step>
+ <title>Specify the test-domain security domain</title>
+ <para>In the target file chosen in step 1, specify the <parameter>test-domain</parameter> security domain. This domain contains the authentication information, including the <sgmltag><login-module></sgmltag> definition, and the JACC authorization policy module definition.</para>
+ <programlisting><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="extras/authorization-policy-specific-security-domain-1.xml_sample" parse="text"/></programlisting>
+ </step>
+ <step>
+ <title>Append the test-domain-inherited security domain</title>
+ <para>Append the <parameter>test-domain-inherited</parameter> application policy definition after the <parameter>test-domain</parameter> application policy. Set the <parameter>extends</parameter> attribute to <literal>other</literal>, so the login module information is inherited. Specify the XACML authorization module in the <sgmltag><policy.module></sgmltag> element.</para>
+ <programlisting><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="extras/authorization-policy-specific-security-domain-2.xml_sample" parse="text"/></programlisting>
+ </step>
+ <step>
+ <title>Restart server</title>
+ <para>You have now configured the target file with two security domains that use different authorization methods.</para>
+ <para>Restart the server to ensure the new security policy takes effect.</para>
+ </step>
+ </procedure>
+ <formalpara>
+ <title>Setting authorization module delegates</title>
+ <para><xref linkend="proc-Set_Auth_Policies_For_All_EJB_WAR_Components"/> and <xref linkend="proc-Set_Auth_Policies_For_Specific_Domains"/> describe simplistic examples that show how authentication and authorization can be configured in security domains. </para>
+ </formalpara>
+ <para>Because authorization relates to the type of component (not the layer) you want to protect, you can use delegation within a deployment descriptor to specify different authorization policies to the standard authentication in your implementation. </para>
+ <para>The delegates must be a subclass of <classname>AuthorizationModuleDelegate</classname>. <xref linkend="exam-security-AuthorizationModuleDelegate_Class"/> describes the base <classname>AuthorizationModuleDelegate</classname> interface. </para>
+ <para> </para>
+ <example id="exam-security-AuthorizationModuleDelegate_Class">
+ <title>AuthorizationModuleDelegate class</title>
+ <programlisting role="JAVA" language="Java"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="extras/security-policies-authorization_delegate_example.java" parse="text"/></programlisting>
+ </example>
+ <para>Some examples of authorization delegation are included for reference. <xref linkend="exam-security-EJBJACCPolicyModuleDelegate_Module"/> describes an authorization module responsible for authorization decisions for the EJB layer. <xref linkend="exam-security-WebJACCPolicyModuleDelegate_Module"/> describes a JACC-based authorization module helper that controls web layer authorization decisions.</para>
+ <example id="exam-security-EJBJACCPolicyModuleDelegate_Module">
+ <title>EJBJACCPolicyModuleDelegate.java</title>
+ <programlisting role="JAVA" language="Java"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="extras/security-policies-EJBJACCPolicyModuleDelegate.java" parse="text"/></programlisting>
+ </example>
+ <example id="exam-security-WebJACCPolicyModuleDelegate_Module">
+ <title>WebJACCPolicyModuleDelegate.java</title>
+ <programlisting role="JAVA" language="Java"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="extras/security-policies-WebJACCPolicyModuleDelegate.java" parse="text"/></programlisting>
+ </example>
+ </section>
<section id="Defining_Security_Domains-Loading_Security_Domains">
<title>Loading Security Domains</title>
<para>
- Authentication security domains are configured statically in the <literal>conf/login-config.xml</literal> file. The <literal>XMLLoginConfig</literal> MBean is responsible for loading security configurations from this configurations from a local configuration file. The MBean is defined as shown below.
+ Authentication security domains are configured statically in the <literal>conf/login-config.xml</literal> file, or deployed using <filename>jboss-beans.xml</filename> deployment descriptors (refer to . For static domains, the <literal>XMLLoginConfig</literal> MBean is responsible for loading security configurations from this configurations from a local configuration file. The MBean is defined as shown below.
</para>
<programlisting><mbean code="org.jboss.security.auth.login.XMLLoginConfig"
name="jboss.security:service=XMLLoginConfig">
Added: projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/authorization-policy-specific-security-domain-1.xml_sample
===================================================================
--- projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/authorization-policy-specific-security-domain-1.xml_sample (rev 0)
+++ projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/authorization-policy-specific-security-domain-1.xml_sample 2010-02-15 07:27:32 UTC (rev 100953)
@@ -0,0 +1,20 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<deployment xmlns="urn:jboss:bean-deployer:2.0">
+
+ <application-policy xmlns="urn:jboss:security-beans:1.0" name="test-domain">
+ <authentication>
+ <login-module code = "org.jboss.security.auth.spi.UsersRolesLoginModule"
+ flag = "required">
+ <module-option name = "unauthenticatedIdentity">anonymous</module-option>
+ <module-option name="usersProperties">u.properties</module-option>
+ <module-option name="rolesProperties">r.properties</module-option>
+ </login-module>
+ </authentication>
+ <authorization>
+ <policy-module code="org.jboss.security.authorization.modules.JACCAuthorizationModule" flag="required"/>
+ </authorization>
+ </application-policy>
+
+
+</deployment>
Added: projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/authorization-policy-specific-security-domain-2.xml_sample
===================================================================
--- projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/authorization-policy-specific-security-domain-2.xml_sample (rev 0)
+++ projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/authorization-policy-specific-security-domain-2.xml_sample 2010-02-15 07:27:32 UTC (rev 100953)
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<deployment xmlns="urn:jboss:bean-deployer:2.0">
+
+ <application-policy xmlns="urn:jboss:security-beans:1.0" name="test-domain">
+ <authentication>
+ <login-module code = "org.jboss.security.auth.spi.UsersRolesLoginModule"
+ flag = "required">
+ <module-option name = "unauthenticatedIdentity">anonymous</module-option>
+ <module-option name="usersProperties">u.properties</module-option>
+ <module-option name="rolesProperties">r.properties</module-option>
+ </login-module>
+ </authentication>
+ <authorization>
+ <policy-module code="org.jboss.security.authorization.modules.JACCAuthorizationModule" flag="required"/>
+ </authorization>
+ </application-policy>
+
+ <application-policy xmlns="urn:jboss:security-beans:1.0" name="test-domain-inherited" extends="other">
+ <authorization>
+ <policy-module code="org.jboss.security.authorization.modules.XACMLAuthorizationModule" flag="required"/>
+ </authorization>
+ </application-policy>
+
+</deployment>
Added: projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/jboss-beans.xml_sample
===================================================================
--- projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/jboss-beans.xml_sample (rev 0)
+++ projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/jboss-beans.xml_sample 2010-02-15 07:27:32 UTC (rev 100953)
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<deployment xmlns="urn:jboss:bean-deployer:2.0">
+
+ <application-policy xmlns="urn:jboss:security-beans:1.0" name="web-test">
+ <authentication>
+ <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
+ <module-option name="unauthenticatedIdentity">anonymous</module-option>
+ <module-option name="usersProperties">u.properties</module-option>
+ <module-option name="rolesProperties">r.properties</module-option>
+ </login-module>
+ </authentication>
+ </application-policy>
+
+ <application-policy xmlns="urn:jboss:security-beans:1.0" name="ejb-test">
+ <authentication>
+ <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
+ <module-option name="unauthenticatedIdentity">anonymous</module-option>
+ <module-option name="usersProperties">u.properties</module-option>
+ <module-option name="rolesProperties">r.properties</module-option>
+ </login-module>
+ </authentication>
+ </application-policy>
+
+</deployment>
Added: projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/security-policies-EJBJACCPolicyModuleDelegate.java
===================================================================
--- projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/security-policies-EJBJACCPolicyModuleDelegate.java (rev 0)
+++ projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/security-policies-EJBJACCPolicyModuleDelegate.java 2010-02-15 07:27:32 UTC (rev 100953)
@@ -0,0 +1,124 @@
+package org.jboss.security.authorization.modules.ejb;
+
+import java.lang.reflect.Method;
+import java.security.CodeSource;
+import java.security.Permission;
+import java.security.Policy;
+import java.security.Principal;
+import java.security.ProtectionDomain;
+import java.util.Map;
+
+import javax.security.auth.Subject;
+import javax.security.jacc.EJBMethodPermission;
+import javax.security.jacc.EJBRoleRefPermission;
+
+import org.jboss.logging.Logger;
+import org.jboss.security.authorization.AuthorizationContext;
+import org.jboss.security.authorization.PolicyRegistration;
+import org.jboss.security.authorization.Resource;
+import org.jboss.security.authorization.ResourceKeys;
+import org.jboss.security.authorization.modules.AbstractJACCModuleDelegate;
+import org.jboss.security.authorization.modules.AuthorizationModuleDelegate;
+import org.jboss.security.authorization.resources.EJBResource;
+import org.jboss.security.identity.Role;
+import org.jboss.security.identity.RoleGroup;
+
+
+//$Id$
+
+/**
+ * Authorization Module delegate that deals with the authorization decisions
+ * for the EJB Layer
+ * @author <a href="mailto:Anil.Saldhana at jboss.org">Anil Saldhana</a>
+ * @since Jul 6, 2006
+ * @version $Revision$
+ */
+public class EJBJACCPolicyModuleDelegate extends AbstractJACCModuleDelegate
+{
+ private String ejbName = null;
+ private Method ejbMethod = null;
+ private String methodInterface = null;
+ private CodeSource ejbCS = null;
+ private String roleName = null;
+ private Boolean roleRefCheck = Boolean.FALSE;
+
+ public EJBJACCPolicyModuleDelegate()
+ {
+ log = Logger.getLogger(getClass());
+ trace = log.isTraceEnabled();
+ }
+
+ /**
+ * @see AuthorizationModuleDelegate#authorize(Resource)
+ */
+ public int authorize(Resource resource, Subject callerSubject, RoleGroup role)
+ {
+ if(resource instanceof EJBResource == false)
+ throw new IllegalArgumentException("resource is not an EJBResource");
+
+ EJBResource ejbResource = (EJBResource) resource;
+
+ //Get the context map
+ Map<String,Object> map = resource.getMap();
+ if(map == null)
+ throw new IllegalStateException("Map from the Resource is null");
+
+ this.policyRegistration = (PolicyRegistration) map.get(ResourceKeys.POLICY_REGISTRATION);
+
+ this.ejbCS = ejbResource.getCodeSource();
+ this.ejbMethod = ejbResource.getEjbMethod();
+ this.ejbName = ejbResource.getEjbName();
+ this.methodInterface = ejbResource.getEjbMethodInterface();
+
+ //isCallerInRole checks
+ this.roleName = (String)map.get(ResourceKeys.ROLENAME);
+
+ this.roleRefCheck = (Boolean)map.get(ResourceKeys.ROLEREF_PERM_CHECK);
+ if(this.roleRefCheck == Boolean.TRUE)
+ return checkRoleRef(callerSubject, role);
+ else
+ return process(callerSubject, role);
+ }
+
+ //Private Methods
+ /**
+ * Process the request
+ * @param request
+ * @param sc
+ * @return
+ */
+ private int process(Subject callerSubject, Role role)
+ {
+ EJBMethodPermission methodPerm =
+ new EJBMethodPermission(ejbName, methodInterface, ejbMethod);
+ boolean policyDecision = checkWithPolicy(methodPerm, callerSubject, role);
+ if( policyDecision == false )
+ {
+ String msg = "Denied: "+methodPerm+", caller=" + callerSubject+", role="+role;
+ if(trace)
+ log.trace("EJB Jacc Delegate:"+msg);
+ }
+ return policyDecision ? AuthorizationContext.PERMIT : AuthorizationContext.DENY;
+ }
+
+ private int checkRoleRef(Subject callerSubject, RoleGroup callerRoles)
+ {
+ //This has to be the EJBRoleRefPermission
+ EJBRoleRefPermission ejbRoleRefPerm = new EJBRoleRefPermission(ejbName,roleName);
+ boolean policyDecision = checkWithPolicy(ejbRoleRefPerm, callerSubject, callerRoles);
+ if( policyDecision == false )
+ {
+ String msg = "Denied: "+ejbRoleRefPerm+", caller=" + callerSubject;
+ if(trace)
+ log.trace("EJB Jacc Delegate:"+msg);
+ }
+ return policyDecision ? AuthorizationContext.PERMIT : AuthorizationContext.DENY;
+ }
+
+ private boolean checkWithPolicy(Permission ejbPerm, Subject subject, Role role)
+ {
+ Principal[] principals = this.getPrincipals(subject, role);
+ ProtectionDomain pd = new ProtectionDomain (ejbCS, null, null, principals);
+ return Policy.getPolicy().implies(pd, ejbPerm);
+ }
+}
Added: projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/security-policies-WebJACCPolicyModuleDelegate.java
===================================================================
--- projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/security-policies-WebJACCPolicyModuleDelegate.java (rev 0)
+++ projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/security-policies-WebJACCPolicyModuleDelegate.java 2010-02-15 07:27:32 UTC (rev 100953)
@@ -0,0 +1,271 @@
+package org.jboss.security.authorization.modules.web;
+
+import java.io.IOException;
+import java.security.CodeSource;
+import java.security.Permission;
+import java.security.Policy;
+import java.security.Principal;
+import java.security.ProtectionDomain;
+import java.util.Map;
+import java.util.Set;
+
+import javax.security.auth.Subject;
+import javax.security.jacc.WebResourcePermission;
+import javax.security.jacc.WebRoleRefPermission;
+import javax.security.jacc.WebUserDataPermission;
+import javax.servlet.http.HttpServletRequest;
+
+import org.jboss.logging.Logger;
+import org.jboss.security.authorization.AuthorizationContext;
+import org.jboss.security.authorization.PolicyRegistration;
+import org.jboss.security.authorization.Resource;
+import org.jboss.security.authorization.ResourceKeys;
+import org.jboss.security.authorization.modules.AbstractJACCModuleDelegate;
+import org.jboss.security.authorization.modules.AuthorizationModuleDelegate;
+import org.jboss.security.authorization.resources.WebResource;
+import org.jboss.security.identity.Role;
+import org.jboss.security.identity.RoleGroup;
+
+
+//$Id: WebJACCPolicyModuleDelegate.java 62923 2007-05-09 03:08:14Z anil.saldhana at jboss.com $
+
+/**
+ * JACC based authorization module helper that deals with the web layer
+ * authorization decisions
+ * @author <a href="mailto:Anil.Saldhana at jboss.org">Anil Saldhana</a>
+ * @since July 7, 2006
+ * @version $Revision: 62923 $
+ */
+public class WebJACCPolicyModuleDelegate extends AbstractJACCModuleDelegate
+{
+ private Policy policy = Policy.getPolicy();
+ private HttpServletRequest request = null;
+ private CodeSource webCS = null;
+
+ private String canonicalRequestURI = null;
+
+ public WebJACCPolicyModuleDelegate()
+ {
+ log = Logger.getLogger(WebJACCPolicyModuleDelegate.class);
+ trace = log.isTraceEnabled();
+ }
+
+ /**
+ * @see AuthorizationModuleDelegate#authorize(Resource)
+ */
+ @SuppressWarnings("unchecked")
+ public int authorize(Resource resource, Subject callerSubject, RoleGroup role)
+ {
+ if(resource instanceof WebResource == false)
+ throw new IllegalArgumentException("resource is not a WebResource");
+
+ WebResource webResource = (WebResource) resource;
+
+ //Get the context map
+ Map<String,Object> map = resource.getMap();
+ if(map == null)
+ throw new IllegalStateException("Map from the Resource is null");
+
+ //Get the Request Object
+ request = (HttpServletRequest) webResource.getServletRequest();
+
+ webCS = webResource.getCodeSource();
+ this.canonicalRequestURI = webResource.getCanonicalRequestURI();
+
+ String roleName = (String)map.get(ResourceKeys.ROLENAME);
+ Principal principal = (Principal)map.get(ResourceKeys.HASROLE_PRINCIPAL);
+ Set<Principal> roles = (Set<Principal>)map.get(ResourceKeys.PRINCIPAL_ROLES);
+ String servletName = webResource.getServletName();
+ Boolean resourceCheck = checkBooleanValue((Boolean)map.get(ResourceKeys.RESOURCE_PERM_CHECK));
+ Boolean userDataCheck = checkBooleanValue((Boolean)map.get(ResourceKeys.USERDATA_PERM_CHECK));
+ Boolean roleRefCheck = checkBooleanValue((Boolean)map.get(ResourceKeys.ROLEREF_PERM_CHECK));
+
+ validatePermissionChecks(resourceCheck,userDataCheck,roleRefCheck);
+
+ boolean decision = false;
+
+ try
+ {
+ if(resourceCheck)
+ decision = this.hasResourcePermission(callerSubject, role);
+ else
+ if(userDataCheck)
+ decision = this.hasUserDataPermission();
+ else
+ if(roleRefCheck)
+ decision = this.hasRole(principal, roleName, roles, servletName);
+ else
+ if(trace)
+ log.trace("Check is not for resourcePerm, userDataPerm or roleRefPerm.");
+ }
+ catch(IOException ioe)
+ {
+ if(trace)
+ log.trace("IOException:",ioe);
+ }
+ return decision ? AuthorizationContext.PERMIT : AuthorizationContext.DENY;
+ }
+
+ /**
+ * @see AuthorizationModuleDelegate#setPolicyRegistrationManager(PolicyRegistration)
+ */
+ public void setPolicyRegistrationManager(PolicyRegistration authzM)
+ {
+ this.policyRegistration = authzM;
+ }
+
+ //****************************************************************************
+ // PRIVATE METHODS
+ //****************************************************************************
+ /** See if the given JACC permission is implied using the caller as
+ * obtained from either the
+ * PolicyContext.getContext(javax.security.auth.Subject.container) or
+ * the info associated with the requestPrincipal.
+ *
+ * @param perm - the JACC permission to check
+ * @param requestPrincpal - the http request getPrincipal
+ * @param caller the authenticated subject obtained by establishSubjectContext
+ * @return true if the permission is allowed, false otherwise
+ */
+ private boolean checkPolicy(Permission perm, Principal requestPrincpal,
+ Subject caller, Role role)
+ {
+ // Get the caller principals, its null if there is no caller
+ Principal[] principals = getPrincipals(caller,role);
+
+ return checkPolicy(perm, principals);
+ }
+
+
+ /** See if the given permission is implied by the Policy. This calls
+ * Policy.implies(pd, perm) with the ProtectionDomain built from the
+ * active CodeSource set by the JaccContextValve, and the given
+ * principals.
+ *
+ * @param perm - the JACC permission to evaluate
+ * @param principals - the possibly null set of principals for the caller
+ * @return true if the permission is allowed, false otherwise
+ */
+ private boolean checkPolicy(Permission perm, Principal[] principals)
+ {
+ ProtectionDomain pd = new ProtectionDomain(webCS, null, null, principals);
+ boolean allowed = policy.implies(pd, perm);
+ if( trace )
+ {
+ String msg = (allowed ? "Allowed: " : "Denied: ") +perm;
+ log.trace(msg);
+ }
+ return allowed;
+ }
+
+ /**
+ * Ensure that the bool is a valid value
+ * @param bool
+ * @return bool or Boolean.FALSE (when bool is null)
+ */
+ private Boolean checkBooleanValue(Boolean bool)
+ {
+ if(bool == null)
+ return Boolean.FALSE;
+ return bool;
+ }
+
+
+ /**
+ * Perform hasResourcePermission Check
+ * @param request
+ * @param response
+ * @param securityConstraints
+ * @param context
+ * @param caller
+ * @return
+ * @throws IOException
+ */
+ private boolean hasResourcePermission(Subject caller, Role role)
+ throws IOException
+ {
+ Principal requestPrincipal = request.getUserPrincipal();
+ WebResourcePermission perm = new WebResourcePermission(this.canonicalRequestURI,
+ request.getMethod());
+ boolean allowed = checkPolicy(perm, requestPrincipal, caller, role );
+ if( trace )
+ log.trace("hasResourcePermission, perm="+perm+", allowed="+allowed);
+ return allowed;
+ }
+
+ /**
+ * Perform hasRole check
+ * @param principal
+ * @param role
+ * @param roles
+ * @return
+ */
+ private boolean hasRole(Principal principal, String roleName,
+ Set<Principal> roles, String servletName)
+ {
+ if(servletName == null)
+ throw new IllegalArgumentException("servletName is null");
+
+ WebRoleRefPermission perm = new WebRoleRefPermission(servletName, roleName);
+ Principal[] principals = {principal};
+ if( roles != null )
+ {
+ principals = new Principal[roles.size()];
+ roles.toArray(principals);
+ }
+ boolean allowed = checkPolicy(perm, principals);
+ if( trace )
+ log.trace("hasRole, perm="+perm+", allowed="+allowed);
+ return allowed;
+ }
+
+ /**
+ * Perform hasUserDataPermission check for the realm.
+ * If this module returns false, the base class (Realm) will
+ * make the decision as to whether a redirection to the ssl
+ * port needs to be done
+ * @param request
+ * @param response
+ * @param constraints
+ * @return
+ * @throws IOException
+ */
+ private boolean hasUserDataPermission() throws IOException
+ {
+ WebUserDataPermission perm = new WebUserDataPermission(this.canonicalRequestURI,
+ request.getMethod());
+ if( trace )
+ log.trace("hasUserDataPermission, p="+perm);
+ boolean ok = false;
+ try
+ {
+ Principal[] principals = null;
+ ok = checkPolicy(perm, principals);
+ }
+ catch(Exception e)
+ {
+ if( trace )
+ log.trace("Failed to checkSecurityAssociation", e);
+ }
+ return ok;
+ }
+
+ /**
+ * Validate that the access check is made only for one of the
+ * following
+ * @param resourceCheck
+ * @param userDataCheck
+ * @param roleRefCheck
+ */
+ private void validatePermissionChecks(Boolean resourceCheck,
+ Boolean userDataCheck, Boolean roleRefCheck)
+ {
+ if(trace)
+ log.trace("resourceCheck="+resourceCheck + " : userDataCheck=" + userDataCheck
+ + " : roleRefCheck=" + roleRefCheck);
+ if((resourceCheck == Boolean.TRUE && userDataCheck == Boolean.TRUE && roleRefCheck == Boolean.TRUE )
+ || (resourceCheck == Boolean.TRUE && userDataCheck == Boolean.TRUE)
+ || (userDataCheck == Boolean.TRUE && roleRefCheck == Boolean.TRUE))
+ throw new IllegalStateException("Permission checks must be different");
+ }
+}
Added: projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/security-policies-authorization_delegate_example.java
===================================================================
--- projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/security-policies-authorization_delegate_example.java (rev 0)
+++ projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/security-policies-authorization_delegate_example.java 2010-02-15 07:27:32 UTC (rev 100953)
@@ -0,0 +1,47 @@
+package org.jboss.security.authorization.modules;
+
+import javax.security.auth.Subject;
+
+import org.jboss.logging.Logger;
+import org.jboss.security.authorization.AuthorizationModule;
+import org.jboss.security.authorization.PolicyRegistration;
+import org.jboss.security.authorization.Resource;
+import org.jboss.security.identity.RoleGroup;
+
+//$Id$
+
+/**
+ * Delegate for Authorization Module
+ * @author <a href="mailto:Anil.Saldhana at jboss.org">Anil Saldhana</a>
+ * @since Jun 19, 2006
+ * @version $Revision$
+ */
+public abstract class AuthorizationModuleDelegate
+{
+ protected static Logger log = Logger.getLogger(AuthorizationModuleDelegate.class);
+ protected boolean trace = false;
+
+ /**
+ * Policy Registration Manager Injected
+ */
+ protected PolicyRegistration policyRegistration = null;
+
+ /**
+ * @see AuthorizationModule#authorize(Resource)
+ * @param resource
+ * @param subject Authenticated Subject
+ * @param role RoleGroup
+ * @return
+ */
+ public abstract int authorize(Resource resource, Subject subject, RoleGroup role);
+
+ /**
+ * Set the PolicyRegistration manager
+ * Will be used to query for the policies
+ * @param authzManager
+ */
+ public void setPolicyRegistrationManager(PolicyRegistration pm)
+ {
+ this.policyRegistration = pm;
+ }
+}
Added: projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/security-policies-authorization_delegate_example.java~
===================================================================
Added: projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/security-policies-jboss-beans_all_ejb_war.xml_sample
===================================================================
--- projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/security-policies-jboss-beans_all_ejb_war.xml_sample (rev 0)
+++ projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/security-policies-jboss-beans_all_ejb_war.xml_sample 2010-02-15 07:27:32 UTC (rev 100953)
@@ -0,0 +1,22 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<deployment xmlns="urn:jboss:bean-deployer:2.0">
+
+ <application-policy xmlns="urn:jboss:security-beans:1.0" name="jboss-web-policy" extends="other">
+ <authorization>
+ <policy-module code="org.jboss.security.authorization.modules.JACCAuthorizationModule" flag="required"/>
+ </authorization>
+ </application-policy>
+
+ <application-policy xmlns="urn:jboss:security-beans:1.0" name="jboss-ejb-policy" extends="other">
+ <authorization>
+ <policy-module code="org.jboss.security.authorization.modules.JACCAuthorizationModule" flag="required"/>
+ </authorization>
+ </application-policy>
+
+ <application-policy xmlns="urn:jboss:security-beans:1.0" name="jacc-test" extends="other">
+ <authorization>
+ <policy-module code="org.jboss.security.authorization.modules.JACCAuthorizationModule" flag="required"/>
+ </authorization>
+ </application-policy>
+
+</deployment>
Added: projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/security-policies-jboss-beans_default.xml_sample
===================================================================
--- projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/security-policies-jboss-beans_default.xml_sample (rev 0)
+++ projects/docs/enterprise/5.1/JBoss_Security_Chapter/en-US/extras/security-policies-jboss-beans_default.xml_sample 2010-02-15 07:27:32 UTC (rev 100953)
@@ -0,0 +1,17 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<deployment xmlns="urn:jboss:bean-deployer:2.0">
+
+ <application-policy xmlns="urn:jboss:security-beans:1.0" name="jboss-web-policy" extends="other">
+ <authorization>
+ <policy-module code="org.jboss.security.authorization.modules.DelegatingAuthorizationModule" flag="required"/>
+ </authorization>
+ </application-policy>
+
+ <application-policy xmlns="urn:jboss:security-beans:1.0" name="jboss-ejb-policy" extends="other">
+ <authorization>
+ <policy-module code="org.jboss.security.authorization.modules.DelegatingAuthorizationModule" flag="required"/>
+ </authorization>
+ </application-policy>
+
+</deployment>
More information about the jboss-cvs-commits
mailing list