geronimo-scm mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From conflue...@apache.org
Subject [CONF] Apache Geronimo v3.0 > Configuring login modules
Date Mon, 31 Jan 2011 02:31:00 GMT
<html>
<head>
    <base href="https://cwiki.apache.org/confluence">
            <link rel="stylesheet" href="/confluence/s/2036/9/4/_/styles/combined.css?spaceKey=GMOxDOC30&amp;forWysiwyg=true"
type="text/css">
    </head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
    <h2><a href="https://cwiki.apache.org/confluence/display/GMOxDOC30/Configuring+login+modules">Configuring
login modules</a></h2>
    <h4>Page <b>edited</b> by             <a href="https://cwiki.apache.org/confluence/display/~maojia508">maojia</a>
    </h4>
        <br/>
                         <h4>Changes (4)</h4>
                                 
    
<div id="page-diffs">
                    <table class="diff" cellpadding="0" cellspacing="0">
    
            <tr><td class="diff-unchanged" >h2. Where&#39;s the login.conf
file? <br> <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">Due
to some limitations in the default configuration implementation, {excerpt}Geronimo replaces
login.conf entirely with one that is configured via GenericSecurityRealm GBeans.{excerpt}
 This lets you deploy the security realm you need with your application and allows you to
dynamically add the login module classes to the server as needed.  You can also distinguish
between the same principal when created by different login modules or security realms. <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">Because
of some limitations in the default configuration implementation, {excerpt}Geronimo replaces
login.conf entirely with security realms that are configured by GenericSecurityRealm GBeans.{excerpt}
 You can deploy the security realm that you need with your application and dynamically add
the login module classes to the server as needed.  You can also distinguish between the same
principals when they are created by different login modules or security realms. <br></td></tr>
            <tr><td class="diff-unchanged" > <br>h2. So how do I configure
a security realm? <br></td></tr>
            <tr><td class="diff-snipped" >...<br></td></tr>
            <tr><td class="diff-unchanged" >* org.apache.geronimo.security.realm.GenericSecurityRealm.KERNEL
- the Geronimo kernel <br>* org.apache.geronimo.security.realm.GenericSecurityRealm.SERVERINFO
- the ServerInfo object that lets you find stuff in the Geronimo server file layout <br></td></tr>
            <tr><td class="diff-changed-lines" >* org.apache.geronimo.security.realm.GenericSecurityRealm.CLASSLOADER
- the classloader of the plugin that defines the security realm.  Note that this <span
class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">may</span>
<span class="diff-added-words"style="background-color: #dfd;">might</span> be
different from the classloader of a plugin that is using the security realm. <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-changed-lines" >If you specify wrap-principals
as false, your login module will work as usual and only its principals will get into the Subject.
 However if you specify wrap-principals as true, Geronimo will also add principals that wrap
your principals and include the login-domain-name and realm-name of the login module and security
realm that created the principal.  This enables your role-principal mapping to distinguish
between the &quot;same&quot; principal that comes from different sources.  For instance,
if you had two <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">ldap</span>
<span class="diff-added-words"style="background-color: #dfd;">LDAP</span> servers
where the groups had the same names but the meaning was different (perhaps users from different
<span class="diff-changed-words">departments)<span class="diff-added-chars"style="background-color:
#dfd;">,</span></span> you can wrap the principals yet still distinguish the
same group based on the different realms.  However, in order to distinguish principals in
this way, we supply each login module with its own empty Subject object.  <span class="diff-changed-words">Therefore<span
class="diff-deleted-chars"style="color:#999;background-color:#fdd;text-decoration:line-through;">
</span>,<span class="diff-added-chars"style="background-color: #dfd;"> </span>a</span>
later login module cannot access the principals added to a Subject by an earlier login module.
 If you need to share information between login modules and also wrap principals, you must
use the shared state map and not the Subject. <br></td></tr>
    
            </table>
    </div>                            <h4>Full Content</h4>
                    <div class="notificationGreySide">
        <h2><a name="Configuringloginmodules-Where%27sthelogin.conffile%3F"></a>Where's
the login.conf file?</h2>

<p>Because of some limitations in the default configuration implementation, Geronimo
replaces login.conf entirely with security realms that are configured by GenericSecurityRealm
GBeans.  You can deploy the security realm that you need with your application and dynamically
add the login module classes to the server as needed.  You can also distinguish between the
same principals when they are created by different login modules or security realms.</p>

<h2><a name="Configuringloginmodules-SohowdoIconfigureasecurityrealm%3F"></a>So
how do I configure a security realm?</h2>

<p>A typical security realm GBean looks like this:</p>

<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
    &lt;gbean name=<span class="code-quote">"test-realm"</span> class=<span
class="code-quote">"org.apache.geronimo.security.realm.GenericSecurityRealm"</span>&gt;
        &lt;attribute name=<span class="code-quote">"realmName"</span>&gt;test-realm&lt;/attribute&gt;
        &lt;xml-reference name=<span class="code-quote">"LoginModuleConfiguration"</span>&gt;
            &lt;lc:login-config xmlns:lc=<span class="code-quote">"http:<span
class="code-comment">//geronimo.apache.org/xml/ns/loginconfig-${geronimoSchemaVersion}"</span>&gt;
</span>                &lt;lc:login-module control-flag=<span class="code-quote">"REQUIRED"</span>
wrap-principals=<span class="code-quote">"<span class="code-keyword">false</span>"</span>&gt;
                    &lt;lc:login-domain-name&gt;test-realm&lt;/lc:login-domain-name&gt;
                    &lt;lc:login-module-class&gt;org.apache.geronimo.itest.TestLoginModule&lt;/lc:login-module-class&gt;
                    &lt;lc:option name=<span class="code-quote">"users"</span>&gt;foo,bar&lt;/lc:option&gt;
                &lt;/lc:login-module&gt;
            &lt;/lc:login-config&gt;
        &lt;/xml-reference&gt;
        &lt;reference name=<span class="code-quote">"ServerInfo"</span>&gt;
            &lt;name&gt;ServerInfo&lt;/name&gt;
        &lt;/reference&gt;
    &lt;/gbean&gt;
</pre>
</div></div>

<p>Most of the innards here are similar to the login.conf file, converted to xml.  You
can include as many login-module elements as you need. The control flag is specified as an
attribute of this element.  Each login module needs a login-domain-name that is unique within
the security realm.  You can include as many options as you need.  Geronimo will supply these
options for all login modules so that the login modules can use them without declaring them
in the configuration:</p>
<ul>
	<li>org.apache.geronimo.security.realm.GenericSecurityRealm.KERNEL - the Geronimo kernel</li>
	<li>org.apache.geronimo.security.realm.GenericSecurityRealm.SERVERINFO - the ServerInfo
object that lets you find stuff in the Geronimo server file layout</li>
	<li>org.apache.geronimo.security.realm.GenericSecurityRealm.CLASSLOADER - the classloader
of the plugin that defines the security realm.  Note that this might be different from the
classloader of a plugin that is using the security realm.</li>
</ul>


<p>If you specify wrap-principals as false, your login module will work as usual and
only its principals will get into the Subject.  However if you specify wrap-principals as
true, Geronimo will also add principals that wrap your principals and include the login-domain-name
and realm-name of the login module and security realm that created the principal.  This enables
your role-principal mapping to distinguish between the "same" principal that comes from different
sources.  For instance, if you had two LDAP servers where the groups had the same names but
the meaning was different (perhaps users from different departments), you can wrap the principals
yet still distinguish the same group based on the different realms.  However, in order to
distinguish principals in this way, we supply each login module with its own empty Subject
object.  Therefore, a later login module cannot access the principals added to a Subject by
an earlier login module.  If you need to share information between login modules and also
wrap principals, you must use the shared state map and not the Subject.</p>
    </div>
        <div id="commentsSection" class="wiki-content pageSection">
        <div style="float: right;">
            <a href="https://cwiki.apache.org/confluence/users/viewnotifications.action"
class="grey">Change Notification Preferences</a>
        </div>
        <a href="https://cwiki.apache.org/confluence/display/GMOxDOC30/Configuring+login+modules">View
Online</a>
        |
        <a href="https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=20645463&revisedVersion=2&originalVersion=1">View
Changes</a>
                |
        <a href="https://cwiki.apache.org/confluence/display/GMOxDOC30/Configuring+login+modules?showComments=true&amp;showCommentArea=true#addcomment">Add
Comment</a>
            </div>
</div>
</div>
</div>
</div>
</body>
</html>

Mime
View raw message