[jbossws-issues] [JBoss JIRA] Updated: (JBWS-1999) WS-Security Usename Token Profile JAAS Implementation for JSE based WebServices

[Darran Lofthouse (JIRA)]

     [ https://jira.jboss.org/jira/browse/JBWS-1999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated JBWS-1999:
-----------------------------------

    Fix Version/s: jbossws-native-3.0.6


> WS-Security Usename Token Profile JAAS Implementation for JSE based WebServices
> -------------------------------------------------------------------------------
>
>                 Key: JBWS-1999
>                 URL: https://jira.jboss.org/jira/browse/JBWS-1999
>             Project: JBoss Web Services
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: jbossws-native, ws-security
>            Reporter: Thomas Diesler
>            Assignee: Darran Lofthouse
>             Fix For: jbossws-native-3.0.6
>
>         Attachments: UserNameTokenProfileMessageHandler.java, WSSecurityManager.java
>
>
> Karl de Boer sais:
> I created a Username TokenProfile implementation where the userid pwd are verified against the active JAAS SecurityManager
> I want to share this with you.
> It appears to me there is only support for EJB based webservices for this. So i had to create it myself in the form of a messagehandler and some glue to integrate with JBossSX.
> In general i think the focus is to much on EJB Based services. I prefer the WSDL first approach to define a proper SOA.
> It is not a perfect implementation. I do'nt do anything with Nonce and Timestamp and i also do not support passwordDigest.
> So i also do not use any keystores (PasswordText is protect by the transport layer in my case (SSL)). I saw there is an issue in JIRA where the keystore shoud not be required. This is such a case.
> I also was surprised that JBossWS does not check anymore for the requires Username section in Jboss-wsse-server.xml. But for this there is also as JIRA issue
> What i did in a separate messagehandler should perhaps be moved to the WSSecurityDispatcher, which takes care of all WSSecurity related stuff.
> To activate the messagehandler processing i simply adjusted the default the standard-jaxws-endpoint-config.xml 
>   <endpoint-config>
>     <config-name>Standard WSSecurity Endpoint</config-name>
>     <post-handler-chains>
>       <javaee:handler-chain>
>         <javaee:protocol-bindings>##SOAP11_HTTP</javaee:protocol-bindings>
>         <javaee:handler>
>           <javaee:handler-name>WSSecurity Handler</javaee:handler-name>
>           <javaee:handler-class>org.jboss.ws.extensions.security.jaxws.WSSecurityHandlerServer</javaee:handler-class>
>         </javaee:handler>
>        <javaee:handler>
>           <javaee:handler-name>UserNameTokenProfileMessageHandler</javaee:handler-name>
>           <javaee:handler-class>nl.jnc.common.services.wssecurity.UserNameTokenProfileMessageHandler</javaee:handler-class>
>         </javaee:handler>
>       </javaee:handler-chain>
>     </post-handler-chains>
>   </endpoint-config>
> I did not investigate how to link the authenticated user (principal) and associated roles to the WebServiceContext. I directly refer to the SecurityAssociation class which stores Subject and Principal in threadlocal.
> In the SEI implementaion is use the princiap and roles like this (cloul be improved):
> private boolean isUserInRole(String roleName) {
> Subject sub = SecurityAssociation.getSubject();
> if (sub != null) {
> Set<Principal> set = SecurityAssociation.getSubject().getPrincipals();
> if (set!= null) {
> for (Principal p : set) {
> if (p instanceof SimpleGroup) {
> SimpleGroup ng = (SimpleGroup) p;
> Enumeration mem = ng.members();
> while (mem.hasMoreElements()) {
> Principal p1 = (Principal) mem.nextElement();
> if (p1.getName().equalsIgnoreCase(roleName)) return true;
> }
> }
> }
> }
> }
> return false;
> }
> Attached you will find the rest. You are free to use it the way you like.
> In the WsSecurityManager you will also find some a method to authenticate a user with a certificate but this is not tested.
> I use the security implementation against an LDAP (LdapLoginModule). The users are system accounts, the data(sections) returned by the service are governed by the roles a system users has.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira