[portal-commits] JBoss Portal SVN: r12813 - in modules/authorization/trunk/documentation/reference-guide/en: modules and 1 other directory.

Author: sohil.shah(a)jboss.com Date: 2009-02-12 20:32:25 -0500 (Thu, 12 Feb 2009) New Revision: 12813 Modified: modules/authorization/trunk/documentation/reference-guide/en/master.xml modules/authorization/trunk/documentation/reference-guide/en/modules/architecture.xml Log: Architecture Chapter Modified: modules/authorization/trunk/documentation/reference-guide/en/master.xml =================================================================== --- modules/authorization/trunk/documentation/reference-guide/en/master.xml 2009-02-12 12:33:40 UTC (rev 12812) +++ modules/authorization/trunk/documentation/reference-guide/en/master.xml 2009-02-13 01:32:25 UTC (rev 12813) @@ -20,4 +20,5 @@ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="modules/profiles.xml" /> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="modules/spi.xml" /> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="modules/examples.xml" /> + <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="modules/sample.xml" /> </book> \ No newline at end of file Modified: modules/authorization/trunk/documentation/reference-guide/en/modules/architecture.xml =================================================================== --- modules/authorization/trunk/documentation/reference-guide/en/modules/architecture.xml 2009-02-12 12:33:40 UTC (rev 12812) +++ modules/authorization/trunk/documentation/reference-guide/en/modules/architecture.xml 2009-02-13 01:32:25 UTC (rev 12813) @@ -9,33 +9,184 @@ </chapterinfo> <title>Architecture</title> <sect1> - <title>Application Integration</title> - <para> - </para> + <title>Overall Architecture</title> + <para> + JBoss Authorization Server architecture consists of two components: + <itemizedlist> + <listitem>Application Framework</listitem> + <listitem>Authorization Server</listitem> + </itemizedlist> + </para> <sect2> - <title>Profiles</title> - <para></para> + <title>Application Framework</title> + <para> + Application Framework consists of a Developer API that is used to integrate an Authorization layer for your application. This allows your Application + components to be free from any embedded Security Logic. The Framework consists of entities that can be used to create custom Authorization layers within the + context of your application, and with Profiles for infrastructure tiers that allows you to integrate Authorization layers as a simple drop in, without + requiring any coding. + </para> + <sect3> + <title>Profiles</title> + <para> + Profiles are complete implementations of an Authorization layer within the context of the infrastructure tier in question. Examples of such profiles + are the <emphasis>HTTP Profile</emphasis> for the HTTP tier, <emphasis>Portal Profile</emphasis> for a Portal/Portlet Container, + <emphasis>Seam Profile</emphasis> for a Web Tier, <emphasis>EJB Profile</emphasis> for the Service Tier, <emphasis>Hibernate/JPA Profile</emphasis> for the + Data Tier, etc + </para> + <para> + Each Profile will produce an Authorization Context with Attribute Values that make sense within the Context of that tier. Here is a simple + snapshot of what a "Permit" Authorization Context would look like + for a simple Policy Rule in each infrastructure tier: + <para> + <emphasis role="bold">"Allow Writing to a File '/developer/index.html', if User is in Role 'Developer'"</emphasis>: + <itemizedlist> + <listitem><emphasis>HTTP Profile</emphasis> : + <para> + <programlisting><![CDATA[ + Resource Attributes: [urlPattern="/developer/index.html"] + + + Action Attributes: [parameter['action']="write"] + + + Subject Attributes: [roles={"project_manager", "developer"}] + ]]> + </programlisting> + </para> + </listitem> + <listitem><emphasis>EJB Profile</emphasis> : + <para> + <programlisting><![CDATA[ + Resource Attributes: [Java Class="org.cms.CMS", Java Method="writeFile"] + + + Environment Attributes: [parameter['fileName']="/developer/index.html"] + + + Subject Attribute: [roles={"project_manager", "developer"}] + ]]> + </programlisting> + </para> + </listitem> + <listitem><emphasis>Hibernate Profile</emphasis> : + <para> + <programlisting><![CDATA[ + Resource Attributes: [Java Class="org.cms.domain.File"] + + + Environment Attributes: [field['fileName']="/developer/index.html"] + + + Subject Attributes: [roles={"project_manager", "developer"}] + ]]> + </programlisting> + </para> + </listitem> + </itemizedlist> + </para> + Note: Which infrastructure profiles you decide to activate within a single Enterprise application is dependent upon the Security requirements + of the application, and the corresponding Policy makeup. + </para> + <para> + Profile Implementations are expected to be complete with the following features: + <itemizedlist> + <listitem><emphasis>A Drop In Authorization Layer</emphasis></listitem> + <listitem><emphasis>Developer Components built on top of the Developer API to develop Policy Provisioning functions (typically used for building Custom GUI)</emphasis></listitem> + <listitem><emphasis>An Optional tier-specific Generic GUI for Policy Provisioning</emphasis></listitem> + </itemizedlist> + </para> + </sect3> + <sect3> + <title>Developer API</title> + <para> + A Developer API is provided by the Framework to develop custom Authorization functionality or for developing Authorization Profiles discussed above. + The Developer API is split into two types. The very low-level API which presents components for the Authorization Concepts discussed in the + <emphasis><link linkend="concepts">Concepts Chapter</link></emphasis>. It also provides a higher-level API consisting of Application level components that are built on top of the + low-level API. The Authorization Server comes packaged with a set of core components which will be discussed in more detail in the + <emphasis><link linkend="api">Developer API Chapter</link></emphasis> + </para> + <para> + Developers can easily create their own custom components using these low-level and/or higher-level components and have these components easily processed by the Authorization Server. + </para> + <para> + The Developer API is used to create the following Authorization functionality: + <itemizedlist> + <listitem> + <emphasis>Custom Authorization Layer</emphasis> + </listitem> + <listitem> + <emphasis>Custom Provisioning Functionality such as Security GUI, Command Line tools, etc</emphasis> + </listitem> + <listitem> + <emphasis>Custom Components</emphasis> + </listitem> + <listitem> + <emphasis>More Profiles</emphasis> + </listitem> + </itemizedlist> + </para> + </sect3> </sect2> <sect2> - <title>Developer API</title> - <para></para> - </sect2> - </sect1> - <sect1> - <title>Authorization Server</title> - <para> - </para> - <sect2> - <title>Enforcement</title> - <para></para> - </sect2> - <sect2> - <title>Policy Provisioning</title> - <para></para> - </sect2> - <sect2> - <title>Policy Store SPI</title> - <para></para> - </sect2> - </sect1> -</chapter> + <title>Authorization Server</title> + <para> + This component provides the runtime, the rules engine, and policy store which performs evaluation of Authorization requests + against the Authorization Policies for the applications. + It is used by the Application/Profile-level Authorization layer to route requests and correspondingly receive "Permit" or "Deny" responses. + The functionality of the Server is split into the following concerns: + </para> + <sect3> + <title>Enforcement</title> + <para> + This component is responsible for processing incoming Authorization requests. It routes these requests to the rules engine, which in turn + responds with a 'Permit' or 'Deny' state for the request. + </para> + <para> + The rules engine used is standards-compliant and uses the industry supported XACML standard. In a nutshell, XACML is an XML based Security Rules + Language, use to define Security Policies. It is also comprehensive in providing robust concepts and architecture recommendations, but its main focus + is the XML-spec to define Security Policies. This system is designed in accordance with these architectural recommendations, and also uses the + XACML XML-spec to represent the Security Policies. + </para> + <para> + It must be noted that the XACML spec is vast and the XML is extremely complex. However, the developers are completely insulated from any XACML XML + via the Developer API. The Developer API is not the same thing as a JAXB model of the XACML spec. The Developer API consists of object oriented + components from the Application domain. The Authorization runtime internally takes care of converting these components into XACML constructs, to be used + by the Authorization Server. + </para> + <para> + The Authorization Server uses the JAXB model provided by the JBossXACML stack, and the XACML implementation provided by Sun Microsystems. + </para> + </sect3> + <sect3> + <title>Policy Provisioning</title> + <para> + This component processes Provisioning requests from Applications. This results in runtime changes to Security policies, and immediate enforcement + of these policies, without requiring any restarting of the infrastructure. + </para> + </sect3> + <sect3> + <title>Policy Store SPI</title> + <para> + This SPI allows storage agnosticity for the Security Policies managed by the Server. By default, it uses relational database storage. However using the SPI + you can store Policies inside JCR Repositories, LDAP repositories, or other storage locations. + </para> + </sect3> + <sect3> + <title>Deployment Options</title> + <para> + The Authorization Server can be deployed and accessed by Enterprise Applications in 2 ways: + <emphasis>Same VM Mode</emphasis>, + <emphasis>Different VM mode</emphasis>, + </para> + <sect4> + <title>Same VM Mode</title> + <para>In this mode the Authorization Server is deployed in the same VM as a JBoss Microcontainer Service. All service requests are local method invocations.</para> + </sect4> + <sect4> + <title>Different VM Mode</title> + <para>In this mode the Authorization Server is deployed in a separate VM than its applications. In this mode, service requests are made via a Remote interface such as REST</para> + </sect4> + </sect3> + </sect2> + </sect1> +</chapter> \ No newline at end of file