src/org/jsecurity/authz/package.html - jsecurity - Git at Google

 <!--
   ~ Licensed to the Apache Software Foundation (ASF) under one
   ~ or more contributor license agreements.  See the NOTICE file
   ~ distributed with this work for additional information
   ~ regarding copyright ownership.  The ASF licenses this file
   ~ to you under the Apache License, Version 2.0 (the
   ~ "License"); you may not use this file except in compliance
   ~ with the License.  You may obtain a copy of the License at
   ~
   ~     http://www.apache.org/licenses/LICENSE-2.0
   ~
   ~ Unless required by applicable law or agreed to in writing,
   ~ software distributed under the License is distributed on an
   ~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
   ~ KIND, either express or implied.  See the License for the
   ~ specific language governing permissions and limitations
   ~ under the License.
   -->
 <html>
 <body>

 Core interfaces and exceptions supporting Authorization (access control).

 <p>JSecurity abbreviates the word 'AuthoriZation' as <tt>authz</tt> to distinguish it seperately from
     'AuthentiCation', abbreviated as <tt>authc</tt>.</p>

 <p>The primary interface of interest, which is the core of JSecurity authorization functionality,
     is the <tt>Authorizer</tt>. This interface handles all aspects of principal-related security and is
     the facade to all other JSecurity authorization components.</p>

 <p>JSecurity has the ability to authorize subjects (a.k.a. users) without being intrusive to
     the application's domain model. Most applications will utilize the concepts of
     <tt>group</tt>s, <tt>role</tt>s, and <tt>permission</tt>s, but JSecurity tries to be
     as non-invasive as possible doesn't require any such interfaces (although a Permission interface
     is made available for fine-grained access control policies if you want to use
     JSecurity's permission support out-of-the-box).</p>

 <p>Although
     it is possible for applications to implement this and other interfaces directly, it is not
     recommended. JSecurity already has base implementations in the
     <tt>org.jsecurity.authz.support</tt> package which
     should be suitable for 99% of deployments.
     Most applications should be able to use these
     existing components via configuration only and be up and running very quickly. See the
     API or the JSecurity.org website quick-start for how to accomplish this
     instead of writing an implementation from scratch.</p>

 <p>Finally, as is the case with most all of JSecurity interfaces and components, they can be used
     programmatically, but it is highly recommended to use the JSecurity JDK 1.5 annotations and/or
     configuration to reduce or eliminate such effort.</p>

 </body>
 </html>
	<!--
	~ Licensed to the Apache Software Foundation (ASF) under one
	~ or more contributor license agreements. See the NOTICE file
	~ distributed with this work for additional information
	~ regarding copyright ownership. The ASF licenses this file
	~ to you under the Apache License, Version 2.0 (the
	~ "License"); you may not use this file except in compliance
	~ with the License. You may obtain a copy of the License at
	~
	~ http://www.apache.org/licenses/LICENSE-2.0
	~
	~ Unless required by applicable law or agreed to in writing,
	~ software distributed under the License is distributed on an
	~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
	~ KIND, either express or implied. See the License for the
	~ specific language governing permissions and limitations
	~ under the License.
	-->
	<html>
	<body>

	Core interfaces and exceptions supporting Authorization (access control).

	<p>JSecurity abbreviates the word 'AuthoriZation' as <tt>authz</tt> to distinguish it seperately from
	'AuthentiCation', abbreviated as <tt>authc</tt>.</p>

	<p>The primary interface of interest, which is the core of JSecurity authorization functionality,
	is the <tt>Authorizer</tt>. This interface handles all aspects of principal-related security and is
	the facade to all other JSecurity authorization components.</p>

	<p>JSecurity has the ability to authorize subjects (a.k.a. users) without being intrusive to
	the application's domain model. Most applications will utilize the concepts of
	<tt>group</tt>s, <tt>role</tt>s, and <tt>permission</tt>s, but JSecurity tries to be
	as non-invasive as possible doesn't require any such interfaces (although a Permission interface
	is made available for fine-grained access control policies if you want to use
	JSecurity's permission support out-of-the-box).</p>

	<p>Although
	it is possible for applications to implement this and other interfaces directly, it is not
	recommended. JSecurity already has base implementations in the
	<tt>org.jsecurity.authz.support</tt> package which
	should be suitable for 99% of deployments.
	Most applications should be able to use these
	existing components via configuration only and be up and running very quickly. See the
	API or the JSecurity.org website quick-start for how to accomplish this
	instead of writing an implementation from scratch.</p>

	<p>Finally, as is the case with most all of JSecurity interfaces and components, they can be used
	programmatically, but it is highly recommended to use the JSecurity JDK 1.5 annotations and/or
	configuration to reduce or eliminate such effort.</p>

	</body>
	</html>