| <HTML> |
| <BODY BGCOLOR="white"> |
| <PRE> |
| <FONT color="green">001</FONT> /*<a name="line.1"></a> |
| <FONT color="green">002</FONT> * Licensed to the Apache Software Foundation (ASF) under one<a name="line.2"></a> |
| <FONT color="green">003</FONT> * or more contributor license agreements. See the NOTICE file<a name="line.3"></a> |
| <FONT color="green">004</FONT> * distributed with this work for additional information<a name="line.4"></a> |
| <FONT color="green">005</FONT> * regarding copyright ownership. The ASF licenses this file<a name="line.5"></a> |
| <FONT color="green">006</FONT> * to you under the Apache License, Version 2.0 (the<a name="line.6"></a> |
| <FONT color="green">007</FONT> * "License"); you may not use this file except in compliance<a name="line.7"></a> |
| <FONT color="green">008</FONT> * with the License. You may obtain a copy of the License at<a name="line.8"></a> |
| <FONT color="green">009</FONT> *<a name="line.9"></a> |
| <FONT color="green">010</FONT> * http://www.apache.org/licenses/LICENSE-2.0<a name="line.10"></a> |
| <FONT color="green">011</FONT> *<a name="line.11"></a> |
| <FONT color="green">012</FONT> * Unless required by applicable law or agreed to in writing,<a name="line.12"></a> |
| <FONT color="green">013</FONT> * software distributed under the License is distributed on an<a name="line.13"></a> |
| <FONT color="green">014</FONT> * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY<a name="line.14"></a> |
| <FONT color="green">015</FONT> * KIND, either express or implied. See the License for the<a name="line.15"></a> |
| <FONT color="green">016</FONT> * specific language governing permissions and limitations<a name="line.16"></a> |
| <FONT color="green">017</FONT> * under the License.<a name="line.17"></a> |
| <FONT color="green">018</FONT> */<a name="line.18"></a> |
| <FONT color="green">019</FONT> package org.apache.shiro.authz;<a name="line.19"></a> |
| <FONT color="green">020</FONT> <a name="line.20"></a> |
| <FONT color="green">021</FONT> /**<a name="line.21"></a> |
| <FONT color="green">022</FONT> * A Permission represents the ability to perform an action or access a resource. A Permission is the most<a name="line.22"></a> |
| <FONT color="green">023</FONT> * granular, or atomic, unit in a system's security policy and is the cornerstone upon which fine-grained security<a name="line.23"></a> |
| <FONT color="green">024</FONT> * models are built.<a name="line.24"></a> |
| <FONT color="green">025</FONT> * <p/><a name="line.25"></a> |
| <FONT color="green">026</FONT> * It is important to understand a Permission instance only represents functionality or access - it does not grant it.<a name="line.26"></a> |
| <FONT color="green">027</FONT> * Granting access to an application functionality or a particular resource is done by the application's security<a name="line.27"></a> |
| <FONT color="green">028</FONT> * configuration, typically by assigning Permissions to users, roles and/or groups.<a name="line.28"></a> |
| <FONT color="green">029</FONT> * <p/><a name="line.29"></a> |
| <FONT color="green">030</FONT> * Most typical systems are what the Shiro team calls <em>role-based</em> in nature, where a role represents<a name="line.30"></a> |
| <FONT color="green">031</FONT> * common behavior for certain user types. For example, a system might have an <em>Aministrator</em> role, a<a name="line.31"></a> |
| <FONT color="green">032</FONT> * <em>User</em> or <em>Guest</em> roles, etc.<a name="line.32"></a> |
| <FONT color="green">033</FONT> * <p/><a name="line.33"></a> |
| <FONT color="green">034</FONT> * But if you have a dynamic security model, where roles can be created and deleted at runtime, you can't hard-code<a name="line.34"></a> |
| <FONT color="green">035</FONT> * role names in your code. In this environment, roles themselves aren't aren't very useful. What matters is what<a name="line.35"></a> |
| <FONT color="green">036</FONT> * <em>permissions</em> are assigned to these roles.<a name="line.36"></a> |
| <FONT color="green">037</FONT> * <p/><a name="line.37"></a> |
| <FONT color="green">038</FONT> * Under this paradigm, permissions are immutable and reflect an application's raw functionality<a name="line.38"></a> |
| <FONT color="green">039</FONT> * (opening files, accessing a web URL, creating users, etc). This is what allows a system's security policy<a name="line.39"></a> |
| <FONT color="green">040</FONT> * to be dynamic: because Permissions represent raw functionality and only change when the application's<a name="line.40"></a> |
| <FONT color="green">041</FONT> * source code changes, they are immutable at runtime - they represent 'what' the system can do. Roles, users, and<a name="line.41"></a> |
| <FONT color="green">042</FONT> * groups are the 'who' of the application. Determining 'who' can do 'what' then becomes a simple exercise of<a name="line.42"></a> |
| <FONT color="green">043</FONT> * associating Permissions to roles, users, and groups in some way.<a name="line.43"></a> |
| <FONT color="green">044</FONT> * <p/><a name="line.44"></a> |
| <FONT color="green">045</FONT> * Most applications do this by associating a named role with permissions (i.e. a role 'has a' collection of<a name="line.45"></a> |
| <FONT color="green">046</FONT> * Permissions) and then associate users with roles (i.e. a user 'has a' collection of roles) so that by transitive<a name="line.46"></a> |
| <FONT color="green">047</FONT> * association, the user 'has' the permissions in their roles. There are numerous variations on this theme<a name="line.47"></a> |
| <FONT color="green">048</FONT> * (permissions assigned directly to users, or assigned to groups, and users added to groups and these groups in turn<a name="line.48"></a> |
| <FONT color="green">049</FONT> * have roles, etc, etc). When employing a permission-based security model instead of a role-based one, users, roles,<a name="line.49"></a> |
| <FONT color="green">050</FONT> * and groups can all be created, configured and/or deleted at runtime. This enables an extremely powerful security<a name="line.50"></a> |
| <FONT color="green">051</FONT> * model.<a name="line.51"></a> |
| <FONT color="green">052</FONT> * <p/><a name="line.52"></a> |
| <FONT color="green">053</FONT> * A benefit to Shiro is that, although it assumes most systems are based on these types of static role or<a name="line.53"></a> |
| <FONT color="green">054</FONT> * dynamic role w/ permission schemes, it does not require a system to model their security data this way - all<a name="line.54"></a> |
| <FONT color="green">055</FONT> * Permission checks are relegated to {@link org.apache.shiro.realm.Realm} implementations, and only those<a name="line.55"></a> |
| <FONT color="green">056</FONT> * implementations really determine how a user 'has' a permission or not. The Realm could use the semantics described<a name="line.56"></a> |
| <FONT color="green">057</FONT> * here, or it could utilize some other mechanism entirely - it is always up to the application developer.<a name="line.57"></a> |
| <FONT color="green">058</FONT> * <p/><a name="line.58"></a> |
| <FONT color="green">059</FONT> * Shiro provides a very powerful default implementation of this interface in the form of the<a name="line.59"></a> |
| <FONT color="green">060</FONT> * {@link org.apache.shiro.authz.permission.WildcardPermission WildcardPermission}. We highly recommend that you<a name="line.60"></a> |
| <FONT color="green">061</FONT> * investigate this class before trying to implement your own <code>Permission</code>s.<a name="line.61"></a> |
| <FONT color="green">062</FONT> *<a name="line.62"></a> |
| <FONT color="green">063</FONT> * @see org.apache.shiro.authz.permission.WildcardPermission WildcardPermission<a name="line.63"></a> |
| <FONT color="green">064</FONT> * @since 0.2<a name="line.64"></a> |
| <FONT color="green">065</FONT> */<a name="line.65"></a> |
| <FONT color="green">066</FONT> public interface Permission {<a name="line.66"></a> |
| <FONT color="green">067</FONT> <a name="line.67"></a> |
| <FONT color="green">068</FONT> /**<a name="line.68"></a> |
| <FONT color="green">069</FONT> * Returns {@code true} if this current instance <em>implies</em> all the functionality and/or resource access<a name="line.69"></a> |
| <FONT color="green">070</FONT> * described by the specified {@code Permission} argument, {@code false} otherwise.<a name="line.70"></a> |
| <FONT color="green">071</FONT> * <p/><a name="line.71"></a> |
| <FONT color="green">072</FONT> * <p>That is, this current instance must be exactly equal to or a <em>superset</em> of the functionalty<a name="line.72"></a> |
| <FONT color="green">073</FONT> * and/or resource access described by the given {@code Permission} argument. Yet another way of saying this<a name="line.73"></a> |
| <FONT color="green">074</FONT> * would be:<a name="line.74"></a> |
| <FONT color="green">075</FONT> * <p/><a name="line.75"></a> |
| <FONT color="green">076</FONT> * <p>If &quot;permission1 implies permission2&quot;, i.e. <code>permission1.implies(permission2)</code> ,<a name="line.76"></a> |
| <FONT color="green">077</FONT> * then any Subject granted {@code permission1} would have ability greater than or equal to that defined by<a name="line.77"></a> |
| <FONT color="green">078</FONT> * {@code permission2}.<a name="line.78"></a> |
| <FONT color="green">079</FONT> *<a name="line.79"></a> |
| <FONT color="green">080</FONT> * @param p the permission to check for behavior/functionality comparison.<a name="line.80"></a> |
| <FONT color="green">081</FONT> * @return {@code true} if this current instance <em>implies</em> all the functionality and/or resource access<a name="line.81"></a> |
| <FONT color="green">082</FONT> * described by the specified {@code Permission} argument, {@code false} otherwise.<a name="line.82"></a> |
| <FONT color="green">083</FONT> */<a name="line.83"></a> |
| <FONT color="green">084</FONT> boolean implies(Permission p);<a name="line.84"></a> |
| <FONT color="green">085</FONT> }<a name="line.85"></a> |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| </PRE> |
| </BODY> |
| </HTML> |
