<!doctype html><htmllang=enclass="js csstransforms3d"><head><metacharset=utf-8><metaname=viewportcontent="width=device-width,initial-scale=1"><metaname=generatorcontent="Hugo 0.80.0"><metaname=descriptioncontent="Strolch is a parameterized framework for use on servers and IoT"><metaname=authorcontent="Robert von Burg"><linkrel=iconhref=/favicon.icotype=image/ico><title>Privileges - Strolch</title><linkhref=/css/nucleus.css?1678977092rel=stylesheet><linkhref=/css/fontawesome-all.min.css?1678977092rel=stylesheet><linkhref=/css/hybrid.css?1678977092rel=stylesheet><linkhref=/css/featherlight.min.css?1678977092rel=stylesheet><linkhref=/css/perfect-scrollbar.min.css?1678977092rel=stylesheet><linkhref=/css/auto-complete.css?1678977092rel=stylesheet><linkhref=/css/atom-one-dark-reasonable.css?1678977092rel=stylesheet><linkhref=/css/theme.css?1678977092rel=stylesheet><linkhref=/css/hugo-theme.css?1678977092rel=stylesheet><linkhref=/css/theme-green.css?1678977092rel=stylesheet><scriptsrc=/js/jquery-3.3.1.min.js?1678977092></script><style>:root#header+#content>#left>#rlblock_left{display:none!important}</style></head><bodydata-url=/documentation/priviles/><navid=sidebar><divid=header-wrapper><divid=header><aid=logohref=/><imgsrc=/logo.png></a></div><divclass=searchbox><labelfor=search-by><iclass="fas fa-search"></i></label><inputdata-search-inputid=search-bytype=searchplaceholder=Search...>
basic form would be Users and Roles, and then validating that an authenticated
user has a given role. In Strolch we go a step further: A User has roles
assigned, and each role has a set of Privileges. The privileges can overlap, a
validation is performed to make sure that the one role doesn’t deny and another
role allows a specific action.</p><p>As explained in
the <ahref=/documentation/runtime-configuration.md>Privilege Configuration</a> section,
users are defined in the <code>PrivilegeUsers.xml</code> file, and roles are defined in the
<code>PrivilegeRoles.xml</code> file.</p><p>Let’s assume the following user and role definition:</p><divclass=highlight><prestyle=color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4><codeclass=language-xmldata-lang=xml><spanstyle=color:#f92672><Users></span>
</code></pre></div><p>This configuration contains one user and one role. The user <code>jill</code> has the role
<code>AppUser</code> and the role <code>AppUser</code> has three privileges assigned.</p><p>Note how the user’s password is configured similar to a unix password
definition: Using the dollar sign & first the hashing algorithm is configured (
algorithm, iterations, key length), then the salt, followed by the password
hash.</p><divclass="notices tip"><p>Note: The password can also still be saved using two separate fields: a salt and
password field. This configuration will be immediately changed to the unix form,
so won’t be described further here.</p></div><p>Further a user always has a firstname and last name. Optionally a locale can be
set, otherwise the system locale is used. The user’s state must be defined as
one of <code>NEW</code>, <code>ENABLED</code>, <code>DISABLED</code>, <code>EXPIRED</code> or <code>SYSTEM</code>. A user can only
authenticate/login with the state <code>ENABLED</code>. A user can have any number of
properties, which can then be used at runtime. A user can also reference any
number of roles, the assigned privilege can overlap, a global configuration mode
defines how duplicate privileges are handled.</p><p>Roles have a name and any number of <code>Privilege</code> definitions. A Privilege has a
name, which in many cases is the name of Java class/interface on which an action
is being invoked. The <code>policy</code> value defines which policy to use when evaluating
the privilege access. The privilege definition is defined in the
<code>PrivilegeConfig.xml</code> and is the name of a class to call for privilege validation.</p><p>Further the privilege definitions can have a <code>AllAllowed</code> boolean flag, or any
number of Allow or Deny values. How these values are interpreted is defined in
the policy implementation. A policy takes three input parameters:</p><ul><li><code>PrivilegeContext</code> → supplied by privilege and gives access to the Certificate,
thus identifying the user for which privilege access is to be validated.</li><li><code>IPrivilege</code> → Contains the privilege values: <code>AllAllowed</code>, <code>Allow</code> and <code>Deny</code></li><li><code>Restrictable</code> → An interface from which the privilege name is retrieved, and
the associated value. The value is an object, and is cast to the relevant
input in the concrete privilege policy.</li></ul><p>The following privilege policies are already implemented:</p><ul><li><code>DefaultPrivilege</code> → simple policy where the passed <code>Restrictable</code> is expected to
return a String value, which is compared with allow and deny values.</li><li>Internal: <code>RoleAccessPrivilege</code> → policy used for the internal privileges
<code>PrivilegeGetRole</code>, <code>PrivilegeAddRole</code>, <code>PrivilegeModifyRole</code> or <code>PrivilegeModifyRole</code></li><li>Internal: <code>UserAccessPrivilege</code> → policy used for the internal privileges
<code>PrivilegeSetUserLocale</code> or <code>PrivilegeSetUserPassword</code></li><li>Internal: <code>UserAccessWithSameOrganisationPrivilege</code> → Same as the
<code>UserAccessPrivilege</code> but expects the authenticated user to have a property
<code>organisation</code> and validates that the user being modified is in the same
organisation.</li><li>Internal: <code>UsernameFromCertificatePrivilege</code> → This policy expects a
<code>Restrictable</code> to return the <code>certificate</code> of another authenticated user and is
used when modifying an authenticated user, i.e. killing a session, or
modifying its current state, e.g. locale etc.</li><li>Internal: <code>UsernameFromCertificateWithSameOrganisationPrivilege</code> → Same as
<code>UsernameFromCertificatePrivilege</code> but expects the authenticated user to have a
property <code>organisation</code> and validates that the user being modified is in the
same organisation.</li></ul><divclass="notices tip"><p>Note: As a rule, the sequence is <code>AllAllowed → Allow → Deny → default deny</code></p></div><footerclass=footline></footer></div></div><divid=navigation><aclass="nav nav-prev"href=/documentation/reports/title=Reports><iclass="fa fa-chevron-left"></i></a><aclass="nav nav-next"href=/plc/title=PLCstyle=margin-right:0><iclass="fa fa-chevron-right"></i></a></div></section><divstyle=left:-1000px;overflow:scroll;position:absolute;top:-1000px;border:none;box-sizing:content-box;height:200px;margin:0;padding:0;width:200px><divstyle=border:none;box-sizing:content-box;height:200px;margin:0;padding:0;width:200px></div></div><scriptsrc=/js/clipboard.min.js?1678977092></script><scriptsrc=/js/perfect-scrollbar.min.js?1678977092></script><scriptsrc=/js/perfect-scrollbar.jquery.min.js?1678977092></script><scriptsrc=/js/jquery.sticky.js?1678977092></script><scriptsrc=/js/featherlight.min.js?1678977092></script><scriptsrc=/js/highlight.pack.js?1678977092></script><script>hljs.initHighlightingOnLoad();</script><scriptsrc=/js/modernizr.custom-3.6.0.js?1678977092></script><scriptsrc=/js/learn.js?1678977092></script><scriptsrc=/js/hugo-learn.js?1678977092></script><scriptsrc=/mermaid/mermaid.js?1678977092></script><script>mermaid.initialize({startOnLoad:true});</script><scripttype=text/javascript>var_paq=window._paq=window._paq||[];_paq.push(["setDocumentTitle",document.domain+"/"+document.title]);_paq.push(["setCookieDomain","*.strolch.li"]);_paq.push(['trackPageView']);_paq.push(['enableLinkTracking']);(function(){varu="https://piwik.eitchnet.ch/";_paq.push(['setTrackerUrl',u+'matomo.php']);_paq.push(['setSiteId','2']);vard=document,g=d.createElement('script'),s=d.getElementsByTagName('script')[0];g.type='text/javascript';g.async=true;g.src=u+'matomo.js';s.parentNode.insertBefore(g,s);})();</script></body></html>