[JBoss Web Services] - password hash values do not match
by yusuf kurt
yusuf kurt [http://community.jboss.org/people/ykurttr] created the discussion
"password hash values do not match"
To view the discussion, visit: http://community.jboss.org/message/536544#536544
--------------------------------------------------------------
Hi, this is my first post on jboss community,
I searched the forum and google but unfortunately could not find an answer to my question.
I have created a ws-secure webservice with jbossws on jboss 5.1.0 with username/password authentication
I am expecting a username and a digested password according to wss-usernametoken profile from my clients,
i successfully created a jbossws-client application which sends username/digested password and is authenticated via my custom usernamepasswordloginmodule.
But one of my webservice client which is implemented by Axis c++ library can not be authenticated although it sends right credentials.When i checked the incoming soap messages both for jbossws client and axis client, i noticed that axis client nonce value is not encoded with BASE64 whilst jbossws nonce value is encoded with BASE64. As a result the created password hash by jbossws client matched the expected password but axis client did not.
Then i checked the document for creation of nonce from oasis.
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-pr... http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-pr...
starting from line 129, it says that:
Note that the nonce is hashed using the octet sequence of its decoded value while the timestamp
is hashed using the octet sequence of its UTF8 encoding as specified in the contents of the
element.
Note that the nonce is hashed using the octet sequence of its decoded value while the timestamp
is hashed using the octet sequence of its UTF8 encoding as specified in the contents of the
element.
Now i am confused, how must be the cretaed nonce, encoded, or plain or decoded(how); is there a conflict with standarts or am i or is axis missing some point?
thank you in advence...
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/536544#536544]
Start a new discussion in JBoss Web Services at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
Re: [jboss-user] [jBPM] - How to assignee this tasks?
by Huisheng Xu
Huisheng Xu [http://community.jboss.org/people/rebody] replied to the discussion
"How to assignee this tasks?"
To view the discussion, visit: http://community.jboss.org/message/536543#536543
--------------------------------------------------------------
Hi Anand,
I think what you want to do is sending message between different branches of process instance. If ADMIN have not assign the task to a employee, the starter of process instance could have a chance to end the process instance. But if ADMIN is already assign the task to a emloyee, the starter of process instance could not cancel the process instance any more. Do you mean that?
Actually there is no way to send message from a branch of process instance to another one. If you use my process sample showing above, No matter what the ADMIN do, the starter could always terminal the whole process instance.
I think you should find a way to create a task to the starter dynamicly and listening the ADMIN's assigning behaviour, if ADMIN already assign the task to other person, you have delete the starter's task.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/536543#536543]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
Re: [jboss-user] [JBoss Web Services Development] - JBWS-2210 : CXF Username Token JAAS integration
by Sergey Beryozkin
Sergey Beryozkin [http://community.jboss.org/people/sergeyb] replied to the discussion
"JBWS-2210 : CXF Username Token JAAS integration"
To view the discussion, visit: http://community.jboss.org/message/536529#536529
--------------------------------------------------------------
Hi Darran
Thanks for the comments.
> The approach of having two interceptors (one for authentication and one for authorization) is probably the biggest part of this problem already solved.
>
> Where this becomes really apparent is where endpoints are deployed as EJB3 session beans, in this case the container can already be configured to perform authentication and authorization - as a deployed session bean can potentially be called from multiple different clients it makes sense for the authorization checks to remain with the bean.
I see. Perhaps in some cases no authorization will be required, so just dropping an authorization interceptor will satisfy such requirements.
> The point of these two comments really is to highlight that this is not just a case of obtaining a Subject from whatever app server you are running in but actually associating the users identity with the request so that is propagates for further calls within the application server. Using the APIs suggested from Anil should help with this so this is just something to keep in mind.
Sure. I saw the following code line in the JBoss Native :
> securityAdaptor.pushSubjectContext(subject, principal, credential);
this is probably to do with what you explained above.
> A final feature related to this that I know there is user demand for would be the ability to annotate the POJO endpoints with the same role annotations as used on EJB3 sesstion beans - we were unable to do this for our Native implementation of this as we had to support JAX-RPC as well as JAX-WS but as this would be JAX-WS only this could be an option and may help simplify the role configuration
I was thinking of adding (at the CXF level) a utility AuthorizingInInterceptor subclass which would be configured with the name of the annotation such as @RolesAllowed that target POJO classes may be annotated with. This interceptor would introspect a given class and return a list of expected roles for a given method name. Perhaps it might help with addressing this requirement
thanks, Sergey
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/536529#536529]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
Re: [jboss-user] [JBoss Web Services Development] - Recent changes on CXF integration
by Alessio Soldano
Alessio Soldano [http://community.jboss.org/people/alessio.soldano%40jboss.com] replied to the discussion
"Recent changes on CXF integration"
To view the discussion, visit: http://community.jboss.org/message/536519#536519
--------------------------------------------------------------
> Alessio Soldano wrote:
>
> Besides this, it's probably interesting to note that for fixing JBWS-2971 I started using another integration hook, ie. the Spring NamespaceHandlerSupport configuration. As you know, we're generating the jboss-cxf.xml file at deploy time and basically leveraging the spring configuration of CXF (in order to allow both stack agnostic deployments and cxf specific deployments to work seamlessly).
> CXF has spring.handler configuration files that map namespaces for elements in the spring xml to default beans. We're now using a custom mapping for the jaxws.endpoint elements, which in the end allows us to overwrite the CXF org.apache.cxf.jaxws.EndpointImpl giving us control over the endpoint start/stop/publish/etc. while still delegating to the CXF one for the core processing.
> Generally speaking, customizing the spring namespace handler configuration for loading different bean parsers is a powerful integration hook, to be considered in addition to the already used setup of CXF Configurer in the Bus.
On this topic, please note the changes for JBWS-2995:
* we now have a custom NamespaceHandlerResolver that is installed in the XmlBeanDefinitionReader used for parsing the jboss-cxf.xml file and controls the way Spring maps namespaces to beans. That basically makes sure our NamespaceHandler customizations are considered first, falling back to the default Spring/CXF resolution when there's nothing JBossWS specific. Before this change, the resolution (spring.handler check oreder) was erroneously depending on classloader internals
* we provide a spring.handler configuration file having our customizations only, no need to merge all the single configurations coming from the CXF component jars. As a side effect, this simplifies the upgrade process when a new Apache CXF release is available.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/536519#536519]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years