[pcraveiro]

Hi Glen,

    Actually, I think the login module configured for the IDP is looking for a user.properties and roles.properties inside the idp.war.

    If you want to use external properties files, use a different login module configuration like this one:

                <security-domain name="idp" cache-type="default">

                    <authentication>

                        <login-module code="UsersRoles" flag="required">

                            <module-option name="usersProperties" value="${jboss.server.config.dir}/custom-users.properties"/>

                            <module-option name="rolesProperties" value="${jboss.server.config.dir}/custom-roles.properties"/>

                        </login-module>

                    </authentication>

                </security-domain>

    Also, the AS 7 comes with a pre-defined Realm called ApplicationRealm and also a security-domain configuration called "others". You can use the same configuration with the benefit that you can use the add-user.sh script to add new users and let the container do the trick for you. Take a look in this article https://community.jboss.org/en/tools/blog/2012/02/29/excited-about-jboss-as-71-part-ii-developer-friendly-security.

Regards,

Pedro Igor

[gerry.matte]

My testing confirms your suggestion.  I removed security-domain cache-test and was able to login to both wars employee and sales with no error messages.

Did you use userid and password = tomcat when testing with your webapps ? 

I did not assume that the idp was using the jboss property files since I had already viewed them and I knew that tomcat was not a valid user.

(A lucky assumption on my part)

[gerry.matte]

Pedro, can you suggest or point me to a database version of the picketlink idp.war example ?

Ideally one that uses the same schema as the Seam 3 Security webapp idmconsole.war ......

I'm really looking for the capabilities described in the Features section at http://www.seamframework.org/Seam3/SecurityModule but I've not been able to successfully test the SSO capability of Seam Security 3.0.0.Final.

I plan to re-test now that I know the Picketlink module has been updated to 2.0.2

It would be a nice option to use native Picketlink rather than seam3 security which layers on top of picketlink.  I'm always in favour of keeping the infrastructure as simple as possible where the impressive additional features of Seam Security aren't needed.

[xumaokui]

Hi,I just downloaded the latest available JBoss Application Server (Version 7.1.1.Final),but cannot open the link to download picketlink-jars-as7-2.0.2.Final.zip,so i just used Piketlink module included in the AS package,and didn't change anything except configured security domain "idp",the problem is that the AS couldnot deploy idp.war(come from picketlink-fed-webapps-as7-assembly-2.0.2.Final.zip).

Here is the server log:

19:03:30,578 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015876: Starting deployment of "idp.war"

19:03:31,781 INFO  [org.picketlink.identity.federation.bindings.tomcat.idp.IDPWebBrowserSSOValve] (MSC service thread 1-4) IDPWebBrowserSSOValve:: Setting the CanonicalizationMethod on XMLSignatureUtil::http://www.w3.org/2001/10/xml-exc-c14n#WithComments

19:03:31,812 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-4) Context [/idp] startup failed due to previous errors: java.lang.NoClassDefFoundError: org/jcp/xml/dsig/internal/dom/XMLDSigRI

    at org.picketlink.identity.federation.bindings.tomcat.idp.IDPWebBrowserSSOValve.start(IDPWebBrowserSSOValve.java:1110) [picketlink-bindings-2.0.2.Final.jar:2.0.2.Final]

    at org.apache.catalina.core.StandardPipeline.start(StandardPipeline.java:235) [jbossweb-7.0.13.Final.jar:]

    at org.apache.catalina.core.StandardContext.start(StandardContext.java:3786) [jbossweb-7.0.13.Final.jar:]

    at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:90) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]

    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)

    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)

    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) [rt.jar:1.6.0_05]

    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) [rt.jar:1.6.0_05]

    at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_05]

Caused by: java.lang.ClassNotFoundException: org.jcp.xml.dsig.internal.dom.XMLDSigRI from [Module "org.picketlink:main" from local module loader @329f3d (roots: F:\jboss-as-7.1.1.Final\modules)]

    at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)

    at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)

    at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)

    at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423)

    at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423)

    at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)

    at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)

    at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [rt.jar:1.6.0_05]

    ... 9 more

It seems that the Picketlick module cannot find the dependency jars which include the class  org/jcp/xml/dsig/internal/dom/XMLDSigRI,and i found this class is include in the JDK runtime lib(rt.jar),so i add this line to the module.xml of sun.jdk   

     <path name="org/jcp/xml/dsig/internal/dom"/>

also add dependency <module name="sun.jdk"/> to module.xml of org.Picketlink. and restart the AS server,new errors occured:

20:10:08,625 INFO  [org.picketlink.identity.federation.bindings.tomcat.idp.IDPWebBrowserSSOValve] (MSC service thread 1-4) IDPWebBrowserSSOValve:: Setting the CanonicalizationMethod on XMLSignatureUtil::http://www.w3.org/2001/10/xml-exc-c14n#WithComments

20:10:08,906 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-4) Context [/idp] startup failed due to previous errors: java.lang.ExceptionInInitializerError

    at org.picketlink.identity.federation.bindings.tomcat.idp.IDPWebBrowserSSOValve.start(IDPWebBrowserSSOValve.java:1110) [picketlink-bindings-2.0.2.Final.jar:2.0.2.Final]

    at org.apache.catalina.core.StandardPipeline.start(StandardPipeline.java:235) [jbossweb-7.0.13.Final.jar:]

    at org.apache.catalina.core.StandardContext.start(StandardContext.java:3786) [jbossweb-7.0.13.Final.jar:]

    at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:90) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]

    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)

    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)

    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) [rt.jar:1.6.0_05]

    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) [rt.jar:1.6.0_05]

    at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_05]

Caused by: java.lang.ClassCastException: org.jcp.xml.dsig.internal.dom.DOMXMLSignatureFactory cannot be cast to javax.xml.crypto.dsig.XMLSignatureFactory

    at javax.xml.crypto.dsig.XMLSignatureFactory.findInstance(XMLSignatureFactory.java:202) [xmlsec-1.5.1.jar:1.5.1]

    at javax.xml.crypto.dsig.XMLSignatureFactory.getInstance(XMLSignatureFactory.java:250) [xmlsec-1.5.1.jar:1.5.1]

    at org.picketlink.identity.federation.core.util.XMLSignatureUtil.getXMLSignatureFactory(XMLSignatureUtil.java:103) [picketlink-fed-2.0.2.Final.jar:2.0.2.Final]

    at org.picketlink.identity.federation.core.util.XMLSignatureUtil.<clinit>(XMLSignatureUtil.java:85) [picketlink-fed-2.0.2.Final.jar:2.0.2.Final]

    ... 9 more

I use jdk1.6 and windows system, anyone suggestions?

[pcraveiro]

Hi Gerry,

     Maybe I did not understand your question, but the IDP and IDM concepts are not the same. The IDM is about a API/application for managing user, roles, groups and associations between them. For this you need a identity store, like a database, to persist that informations.

     The IDP has no schema, it uses JAAS to authenticate users using a identity store managed by a IDM solution (in your case the idmconsole.war).

Regards.

Pedro Igor

[pcraveiro]

Hi maoki,

     There is a class loader issue with AS 7.1.1.Final that avoids PL to find some xml sign related classes.

     To workaround this, you have to change the module sun.jdk configuration (${jboss.home.dir}/modules/sun/jdk/main/module.xml) like this:

<module xmlns="urn:jboss:module:1.1" name="sun.jdk">

    <resources>

        <!-- currently jboss modules has not way of importing services from

        classes.jar so we duplicate them here -->

        <resource-root path="service-loader-resources"/>

    </resources>

    <dependencies>

        <system export="true">

            <paths>

                <path name="com/sun/script/javascript"/>

                <path name="com/sun/jndi/dns"/>

                <path name="com/sun/jndi/ldap"/>

                <path name="com/sun/jndi/url"/>

                <path name="com/sun/jndi/url/dns"/>

                <path name="com/sun/security/auth"/>

                <path name="com/sun/security/auth/login"/>

                <path name="com/sun/security/auth/module"/>

                <path name="sun/misc"/>

                <path name="sun/io"/>

                <path name="sun/nio"/>

                <path name="sun/nio/ch"/>

                <path name="sun/security"/>

                <path name="sun/security/krb5"/>

                <path name="sun/util"/>

                <path name="sun/util/calendar"/>

                <path name="sun/util/locale"/>

                <path name="sun/security/provider"/>

                <path name="javax/xml/crypto/dsig"/>

                <path name="javax/xml/crypto"/>

                <path name="org/jcp/xml/dsig/internal/dom"/>

                <path name="META-INF/services"/>

            </paths>

            <exports>

                <include-set>

                    <path name="META-INF/services"/>

                </include-set>

            </exports>

        </system>

    </dependencies>

</module>

     Please let me know if you have any doubts.

Regards.

Pedro Igor

[gerry.matte]

Thanks Pedro.  I do understand the distinction in between IDP and IDM (I think).  What remains unclear is how to configure each component to use the same identity store - preferably a JpaIdentityStore as defined in the seam-security documentation.  Over the last few days, I've been forced to spend time on other details of my life so I've not been able to delve into the picketlink documentation much ..... but with a quick scan I was unable to see any documentation on how to configure picketlink to use a database as an identity store.

Don't spend much time or energy on this question unless you prefer to do so.  I'm aware that I need to do my own research if the answer is buried in the documentation.  A point to the right direction would be appreciated .....

Thanks again

Gerry

[pcraveiro]

Hi Gerry,

    The IDP uses JAAS during the authentication process. I think It is a matter of which LoginModule implementation you want. If you want to use a database as an identity store, there is an out-of-box LoginModule called org.jboss.security.auth.spi.DatabaseServerLoginModule. If you want to use a LDAP identity store there is also another implementation.

    You can also create a custom LoginModule to do what ever you want to ....

    Take a look at this documentation: http://docs.jboss.org/jbosssecurity/docs/6.0/security_guide/html/Login_Modules.html

Regards.

Pedro Igor

[gerry.matte]

Thanks Pedro.

It's been a while since I read that chapter so I've likely forgotten it's relevance.

Thanks for giving me the right course to set out upon.

Gerry

[xumaokui]

Thanks Pedro.I modified the module sun.jdk configuration as you said,the second error still exist:

Caused by: java.lang.ClassCastException: org.jcp.xml.dsig.internal.dom.DOMXMLSignatureFactory cannot be cast to javax.xml.crypto.dsig.XMLSignatureFactory

I think the problem is related with XMLSignatureFactory. Here is souce code segment in org.picketlink.identity.federation.core.util.XMLSignatureUtil.java

   private static XMLSignatureFactory getXMLSignatureFactory()

   {

      XMLSignatureFactory xsf = null;

      try

      {

         xsf = XMLSignatureFactory.getInstance("DOM");

      }

      catch (Exception err)

      {

         // JDK5

         xsf = XMLSignatureFactory.getInstance("DOM", new org.jcp.xml.dsig.internal.dom.XMLDSigRI());

      }

      return xsf;

   }

Now I return to JbossAs7.1.0.Final+PicketLink-2.0.2.Final,and it works fine.

Thanks anyway.

[pcraveiro]

Hi maokui,

    I did not tell you to change the module.xml for the org.picketlink module too. Sorry about that. Here is the configuration:

<module xmlns="urn:jboss:module:1.1" name="org.picketlink">

    <resources>

        <resource-root path="picketlink-fed-2.0.2.Final.jar"/>

        <resource-root path="picketlink-bindings-2.0.2.Final.jar"/>

        <resource-root path="picketlink-bindings-jboss-2.0.2.Final.jar"/>

        <!-- Insert resources here -->

    </resources>

    <dependencies>

        <module name="javax.api"/>

        <module name="javax.security.auth.message.api"/>

        <module name="javax.security.jacc.api"/>

        <module name="javax.transaction.api"/>

        <module name="javax.xml.bind.api"/>

        <module name="javax.xml.stream.api"/>

        <module name="javax.servlet.api"/>

        <module name="org.jboss.common-core"/>

        <module name="org.jboss.logging"/>

        <module name="org.jboss.as.web"/>

        <module name="org.jboss.security.xacml"/>

        <module name="org.picketbox"/>

        <module name="javax.xml.ws.api"/>

        <module name="org.apache.log4j"/>

        <!--module name="org.apache.santuario.xmlsec"/--> <!-- Comment this line -->

        <module name="sun.jdk"/> <!-- Add this module dependency -->  

</module>

Regards.

Pedro Igor

[mazzag]

Excellent, thanks, that solved it.  Yes, I forgot to add the ${jboss.server.config.dir} prefix.

Anil, you might wish to add one more sentence to add to your "How-to-install-PL-on A7.1.0" notes:  "Also for any user and role property files declared within these security modules, be sure to prefix them with "${jboss.server.config.dir}/" if you're placing them in the AS7's standalone/configuration folder instead of within the WAR files themselves."  For those accustomed to Tomcat deployment, it's not immediately obvious that prefix would be needed.

[xumaokui]

Hi,Pedro

     Thanks,I changed the the module.xml for the org.picketlink module,and it really works.

Regards.

[mazzag]

Anil, would the lack of the trust JAR prevent pdp.war (https://community.jboss.org/wiki/XACMLPDPSOAPService) from working, or like the STS it should be fine even if that JAR is not present?  I'm trying to get the PDP WAR to work (just started looking at it) and would like to confirm that it's not a losing effort if that JAR isn't around.  Thanks.

[anil.saldhana]

Glen Mazza wrote:

Anil, would the lack of the trust JAR prevent pdp.war (https://community.jboss.org/wiki/XACMLPDPSOAPService) from working, or like the STS it should be fine even if that JAR is not present?  I'm trying to get the PDP WAR to work (just started looking at it) and would like to confirm that it's not a losing effort if that JAR isn't around.  Thanks.

Glen, unfortunately for the PDP to work, I need to tackle https://issues.jboss.org/browse/SECURITY-653

We are still trying to get all our components to work fully in AS7.x and it will take some time.