[jboss-user] [Security] - Re: Problem with Negotiation-toolkit with LDAP
TD403
do-not-reply at jboss.com
Mon Aug 31 06:20:55 EDT 2009
Hi nulltransfer
login-config:
<?xml version='1.0'?>
<!DOCTYPE policy PUBLIC
"-//JBoss//DTD JBOSS Security Config 3.0//EN"
"http://www.jboss.org/j2ee/dtd/security_config.dtd">
<!-- The XML based JAAS login configuration read by the
org.jboss.security.auth.login.XMLLoginConfig mbean. Add
an application-policy element for each security domain.
The outline of the application-policy is:
<application-policy name="security-domain-name">
<login-module code="login.module1.class.name" flag="control_flag">
<module-option name = "option1-name">option1-value</module-option>
<module-option name = "option2-name">option2-value</module-option>
...
</login-module>
<login-module code="login.module2.class.name" flag="control_flag">
...
</login-module>
...
</application-policy>
$Revision: 64598 $
-->
<!-- Used by clients within the application server VM such as
mbeans and servlets that access EJBs.
-->
<application-policy name = "client-login">
<login-module code = "org.jboss.security.ClientLoginModule"
flag = "required">
<!-- Any existing security context will be restored on logout -->
<module-option name="restore-login-identity">true</module-option>
</login-module>
</application-policy>
<!-- Security domain for JBossMQ -->
<application-policy name = "jbossmq">
<login-module code = "org.jboss.security.auth.spi.DatabaseServerLoginModule"
flag = "required">
<module-option name = "unauthenticatedIdentity">guest</module-option>
<module-option name = "dsJndiName">java:/DefaultDS</module-option>
<module-option name = "principalsQuery">SELECT PASSWD FROM JMS_USERS WHERE USERID=?</module-option>
<module-option name = "rolesQuery">SELECT ROLEID, 'Roles' FROM JMS_ROLES WHERE USERID=?</module-option>
</login-module>
</application-policy>
<!-- Security domain for JBossMQ when using file-state-service.xml
<application-policy name = "jbossmq">
<login-module code = "org.jboss.mq.sm.file.DynamicLoginModule"
flag = "required">
<module-option name = "unauthenticatedIdentity">guest</module-option>
<module-option name = "sm.objectname">jboss.mq:service=StateManager</module-option>
</login-module>
</application-policy>
-->
<!-- Security domains for testing new jca framework -->
<application-policy name = "HsqlDbRealm">
<login-module code = "org.jboss.resource.security.ConfiguredIdentityLoginModule"
flag = "required">
<module-option name = "principal">sa</module-option>
<module-option name = "userName">sa</module-option>
<module-option name = "password"></module-option>
<module-option name = "managedConnectionFactoryName">jboss.jca:service=LocalTxCM,name=DefaultDS</module-option>
</login-module>
</application-policy>
<application-policy name = "JmsXARealm">
<login-module code = "org.jboss.resource.security.ConfiguredIdentityLoginModule"
flag = "required">
<module-option name = "principal">guest</module-option>
<module-option name = "userName">guest</module-option>
<module-option name = "password">guest</module-option>
<module-option name = "managedConnectionFactoryName">jboss.jca:service=TxCM,name=JmsXA</module-option>
</login-module>
</application-policy>
<!-- A template configuration for the jmx-console web application. This
defaults to the UsersRolesLoginModule the same as other and should be
changed to a stronger authentication mechanism as required.
-->
<application-policy name = "jmx-console">
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
flag = "required">
<module-option name="usersProperties">props/jmx-console-users.properties</module-option>
<module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>
</login-module>
</application-policy>
<!-- A template configuration for the web-console web application. This
defaults to the UsersRolesLoginModule the same as other and should be
changed to a stronger authentication mechanism as required.
-->
<application-policy name = "web-console">
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
flag = "required">
<module-option name="usersProperties">web-console-users.properties</module-option>
<module-option name="rolesProperties">web-console-roles.properties</module-option>
</login-module>
</application-policy>
<!--
A template configuration for the JBossWS security domain.
This defaults to the UsersRolesLoginModule the same as other and should be
changed to a stronger authentication mechanism as required.
-->
<application-policy name="JBossWS">
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
flag="required">
<module-option name="usersProperties">props/jbossws-users.properties</module-option>
<module-option name="rolesProperties">props/jbossws-roles.properties</module-option>
<module-option name="unauthenticatedIdentity">anonymous</module-option>
</login-module>
</application-policy>
<!-- The default login configuration used by any security domain that
does not have a application-policy entry with a matching name
-->
<application-policy name = "other">
<!-- A simple server login module, which can be used when the number
of users is relatively small. It uses two properties files:
users.properties, which holds users (key) and their password (value).
roles.properties, which holds users (key) and a comma-separated list of
their roles (value).
The unauthenticatedIdentity property defines the name of the principal
that will be used when a null username and password are presented as is
the case for an unuathenticated web client or MDB. If you want to
allow such users to be authenticated add the property, e.g.,
unauthenticatedIdentity="nobody"
-->
<login-module code = "org.jboss.security.auth.spi.UsersRolesLoginModule"
flag = "required" />
</application-policy>
<application-policy name="host">
<login-module code="com.sun.security.auth.module.Krb5LoginModule" flag="required">
<module-option name="storeKey">true</module-option>
<module-option name="useKeyTab">true</module-option>
<module-option name="principal">HTTP/cumpu553.company.nl at COMPANY.NL</module-option>
<module-option name="keyTab">c:\webserver.keytab</module-option>
<module-option name="doNotPrompt">true</module-option>
<module-option name="debug">true</module-option>
</login-module>
</application-policy>
<application-policy name="SPNEGO">
<login-module code="org.jboss.security.negotiation.spnego.SPNEGOLoginModule" flag="requisite">
<module-option name="password-stacking">useFirstPass</module-option>
<module-option name="serverSecurityDomain">host</module-option>
</login-module>
<login-module code="org.jboss.security.negotiation.spnego.AdvancedLdapLoginModule" flag="required">
<module-option name="password-stacking">useFirstPass</module-option>
<module-option name="bindAuthentication">GSSAPI</module-option>
<module-option name="jaasSecurityDomain">host</module-option>
<module-option name="java.naming.provider.url">ldap://cumpu552:389</module-option>
<module-option name="baseCtxDN">cn=users,dc=company,dc=nl</module-option>
<module-option name="baseFilter">(krbPrincipalName={0})</module-option>
<module-option name="roleAttributeID">memberOf</module-option>
<module-option name="roleAttributeIsDN">true</module-option>
<module-option name="roleNameAttributeID">cn</module-option>
<module-option name="recurseRoles">true</module-option>
</login-module>
</application-policy>
jboss-service.xml:
<?xml version="1.0" encoding="UTF-8"?>
<!-- $Id: jboss-service.xml 75558 2008-07-09 16:50:17Z bstansberry at jboss.com $ -->
<!-- JBossWeb Service-->
<mbean code="org.jboss.web.tomcat.service.JBossWeb"
name="jboss.web:service=WebServer" xmbean-dd="META-INF/webserver-xmbean.xml">
<!-- You can configure a set of authenticators keyed by http-auth method used. This
will apply the same set of authenticators across all web applications. You can
override the set of authenticators at the web application level by adding
element to the respective jboss-web.xml -->
<!--
-->
<java:properties xmlns:java="urn:jboss:java-properties"
xmlns:xs="http://www.w3.org/2001/XMLSchema-instance"
xs:schemaLocation="urn:jboss:java-properties resource:java-properties_1_0.xsd">
<java:property>
<java:key>BASIC</java:key>
<java:value>org.apache.catalina.authenticator.BasicAuthenticator</java:value>
</java:property>
<java:property>
<java:key>CLIENT-CERT</java:key>
<java:value>org.apache.catalina.authenticator.SSLAuthenticator</java:value>
</java:property>
<java:property>
<java:key>DIGEST</java:key>
<java:value>org.apache.catalina.authenticator.DigestAuthenticator</java:value>
</java:property>
<java:property>
<java:key>FORM</java:key>
<java:value>org.apache.catalina.authenticator.FormAuthenticator</java:value>
</java:property>
<java:property>
<java:key>NONE</java:key>
<java:value>org.apache.catalina.authenticator.NonLoginAuthenticator</java:value>
</java:property>
<java:property>
<java:key>SPNEGO</java:key>
<java:value>org.jboss.security.negotiation.spnego.SPNEGOAuthenticator</java:value>
</java:property>
</java:properties>
<!-- The JAAS security domain to use in the absense of an explicit
security-domain specification in the war WEB-INF/jboss-web.xml
-->
java:/jaas/other
<!-- Get the flag indicating if the normal Java2 parent first class
loading model should be used over the servlet 2.3 web container first
model.
-->
false
<!-- A flag indicating if the JBoss Loader should be used. This loader
uses a unified class loader as the class loader rather than the tomcat
specific class loader.
The default is false to ensure that wars have isolated class loading
for duplicate jars and jsp files.
-->
false
<!-- The list of package prefixes that should not be loaded without
delegating to the parent class loader before trying the web app
class loader. The packages listed here are those tha are used by
the web container implementation and cannot be overriden. The format
is a comma separated list of the package names. There cannot be any
whitespace between the package prefixes.
This setting only applies when UseJBossWebLoader=false.
-->
javax.servlet
true
<!--Flag to delete the Work Dir on Context Destroy -->
false
<!--
Class of the session manager (used if context is marked as 'distributable'. Currently allowed values:
- org.jboss.web.tomcat.service.session.JBossCacheManager
-->
org.jboss.web.tomcat.service.session.JBossCacheManager
<!-- The name of the request attribute under with the authenticated JAAS
Subject is stored on successful authentication. If null or empty then
the Subject will not be stored.
-->
<!--
j_subject
-->
<!-- The SessionIdAlphabet is the set of characters used to create a session Id
It must be made up of exactly 65 unique characters
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+-*
-->
<!--
*******************************************************
****************** CLUSTERING *************************
*******************************************************
In order to activate HTTP Session clustering for Tomcat
make sure you run JBoss's "all" configuration i.e.
"run -c all"
(the default configuration doesn't contain clustering)
Furthermore, you may change SnapshotMode and
SnapshotInterval attributes below to indicate when to
synchronize changes with the other node(s).
If you use Apache+mod_jk(2) you will most probably use
the AJP1.3 connector below. Thus, if you so wish,
you may comment (i.e. deactivate) the HTTP connector
as it won't be used anymore.
*******************************************************
*******************************************************
*******************************************************
-->
<!--
If you are using clustering, the following two attributes
define when the sessions are replicated to the other nodes.
The default value, "instant", synchronously replicates changes
to the other nodes at the end of requests. In this case, the
"SnapshotInterval" attribute is not used.
The "interval" mode, in association with the "SnapshotInterval"
attribute, indicates that modified sessions will only be replicated
every "SnapshotInterval" milliseconds at most.
Note that this attribute is not in effect if the replication-granularity
is set to FIELD. If it is FIELD, it will be per http request (that is,
"instant" mode.)
-->
instant <!-- you may switch to "interval" -->
2000
<!--
Whether to use MOD_JK(2) for load balancing with sticky session
combined with JvmRoute. If set to true, it will insert a JvmRouteFilter
to intercept every request and replace the JvmRoute if it detects a
failover. In addition, you will need to set the JvmRoute inside
Tomcat, e.g.,
Engine name="jboss.web" jmvRoute="Node1" defaultHost="localhost"
in server.xml.
For clustering purpose only.
-->
false
<!--
Clustering only: Determines the maximum interval between requests, in
seconds, after which a request will trigger replication of the session's
timestamp and other metadata regardless of whether the request has otherwise
made the session dirty. Such replication ensures that other nodes in the
cluster are aware of the most recent value for the session's timestamp
and won't incorrectly expire an unreplicated session upon failover. It also
results in correct values for HttpSession.getLastAccessedTime() calls
following failover.
The cost of this metadata replication depends on the configured
replication-granularity. With SESSION, the session's
attribute map is replicated along with the metadata, so it can be fairly
costly. With other granularities, the metadata object is replicated
separately from the attributes and only contains a String, and a few longs,
ints and booleans.
A value of 0 means the metadata will be replicated whenever the session is
accessed. A value of -1 means the metadata will be replicated only if some
other activity during the request (e.g. modifying an attribute) has
resulted in other replication work involving the session. A positive value
greater than the HttpSession.getMaxInactiveInterval() value will be treated
as a likely misconfiguration and converted to 0; i.e. replicate the
metadata on every request.
Default value if unconfigured is 60 seconds.
-->
60
jboss.web
<!-- A mapping to the server security manager service which must be
operation compatible with type
org.jboss.security.plugins.JaasSecurityManagerServiceMBean. This is only
needed if web applications are allowed to flush the security manager
authentication cache when the web sessions invalidate.
-->
<depends optional-attribute-name="SecurityManagerService"
proxy-type="attribute">jboss.security:service=JaasSecurityManager
<!--
Needed if using HTTP Session Clustering or if the
ClusteredSingleSignOn valve is enabled in the tomcat server.xml file
-->
<!--
jboss.cache:service=TomcatClusteringCache
-->
jboss:service=TransactionManager
<!-- Only needed if the org.jboss.web.tomcat.service.jca.CachedConnectionValve
is enabled in the tomcat server.xml file.
-->
jboss.jca:service=CachedConnectionManager
run.bat:
C:\jboss-4.2.3.GA\bin\run.bat -b 0.0.0.0 -Djava.security.krb5.realm=COMPANY.NL -Djava.security.krb5.kdc=compu552.company.nl -Dsun.security.krb5.debug=true
properties-service:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE server>
<!-- $Id: properties-service.xml 16662 2003-08-27 04:38:22Z patriot1burke $ -->
<!-- ==================================================================== -->
<!-- PropertyEditorManager Service -->
<!-- ==================================================================== -->
<!--
| Allows access to the PropertyEditorManager, which is used when setting
| MBean attribute values from configuration.
-->
<!--
| Register and editor for each of the type_name=editor_type_name listed
| in properties file style convetion.
java.net.URL=my.project.editors.URLPropertyEditor
-->
<!-- ==================================================================== -->
<!-- System Properties Service -->
<!-- ==================================================================== -->
<!--
| Allows rich access to system properties.
-->
java.security.krb5.kdc=cumpu552.company.nl
java.security.krb5.realm=COMPANY.NL
<!--
| Load properties from each of the given comma seperated URLs
http://somehost/some-location.properties,
./conf/somelocal.properties
-->
<!--
| Set raw properties file style properties.
my.project.property=This is the value of my property
my.project.anotherProperty=This is the value of my other property
-->
I hope this helps.
Thanks for all your help.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252569#4252569
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252569
More information about the jboss-user
mailing list