Ok, so i'm thinking about something like that :
In ws-security properties you can change default Crypto provider to
xfire provider and specify decryptor class responsible for decryption
encrypted string from property file
Before:
org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
org.apache.ws.security.crypto.merlin.keystore.type=jks
org.apache.ws.security.crypto.merlin.keystore.password=keystorePass
org.apache.ws.security.crypto.merlin.alias.password=aliaspass
org.apache.ws.security.crypto.merlin.keystore.alias=serveralias
org.apache.ws.security.crypto.merlin.file=META-INF/xfire/serverStore.jks
After:
org.apache.ws.security.crypto.provider=org.codehaus.xfire.crytpo.TSProvider
org.codehaus.xfire.crypto.SecretDecrypter=foo.bar.MyEncrypter
org.apache.ws.security.crypto.merlin.keystore.type=jks
org.apache.ws.security.crypto.merlin.keystore.password=DK#o303L$KDOG(_
org.apache.ws.security.crypto.merlin.alias.password=NI#6LDL3l30L2D
org.apache.ws.security.crypto.merlin.keystore.alias=serveralias
org.apache.ws.security.crypto.merlin.file=META-INF/xfire/serverStore.jks
Decrypter can be defined as following:
public abstract class PassDecrypter{
String decryptString(String value );
}
What do you think ? Any comments ?
On 3/21/07, Andres Bernasconi <[EMAIL PROTECTED]> wrote:
I think that will be super. The more plug-and-play you can make XFire to be,
the more popularity it will gain. ;) (that's why I added XFIRE-916)
Going back to the WS-Security header stuff, I think that's totally insane :)
but that's just my opinion lol.
Regards
On 3/21/07, Tomek Sztelak <[EMAIL PROTECTED]> wrote:
> I think its a standard.
>
> Btw, i think i can add crytpoprovider with password encryption to
distribution.
>
> On 3/21/07, Andres Bernasconi <[EMAIL PROTECTED] > wrote:
> > Finally,
> >
> > after adding UsernameToken security to a web service, I see that there
is no
> > reference or mention in the WSDL that the service requires such
> > authentication method. (I don't know why but) I would have expected the
WSDL
> > to show that it requires such header for incoming requests since it is
part
> > of the "contract" I enfornce, but it is not there.
> >
> > Is this an XFire or a Standards thing?
> >
> > Regards
> > Andres B.
> >
> >
> > On 3/20/07, Tomek Sztelak <[EMAIL PROTECTED] > wrote:
> > > Sorry, i didn't have time to look , kinda busy these days :( But i'll
> > > check it sometime later.
> > >
> > > On 3/20/07, Andres Bernasconi <[EMAIL PROTECTED]> wrote:
> > > > Tomek, were you able to look at the XFIRE-916 ? do you think it's
> > feasible?
> > > >
> > > > Regards
> > > > AB
> > > >
> > > >
> > > > On 3/19/07, Andres Bernasconi < [EMAIL PROTECTED] > wrote:
> > > > > oki, thanks. If this is the "best practice", it might be good to
have
> > an
> > > > "out-of-the-box" solution, ready for production environment.
> > > > >
> > > > > Regards
> > > > > Andrés B.
> > > > >
> > > > >
> > > > >
> > > > > On 3/19/07, Tomek Sztelak < [EMAIL PROTECTED]> wrote:
> > > > > > I don't use WS-Sec, so no :) But someone on mailing list
mentioned
> > he
> > > > does.
> > > > > >
> > > > > > On 3/19/07, Andres Bernasconi < [EMAIL PROTECTED]>
wrote:
> > > > > > > do YOU do it like that?
> > > > > > >
> > > > > > >
> > > > > > > On 3/19/07, Tomek Sztelak < [EMAIL PROTECTED]> wrote:
> > > > > > > >
> > > > > > > > Hi
> > > > > > > >
> > > > > > > >
> > > > > > > > On 3/18/07, Andres Bernasconi < [EMAIL PROTECTED]>
> > wrote:
> > > > > > > > > Hi all,
> > > > > > > > >
> > > > > > > > > First of all, I wanted to suggest that the USER used in
the
> > > > Encryption
> > > > > > > > > example of XFire's WS-Security page be set to "myAlias",
since
> > > > that's
> > > > > > > the
> > > > > > > > > name used when the keys were created (instead of
> > myserveralias).
> > > > > > > > >
> > > > > > > > > Second, I wanted to know how all this would work in
> > production,
> > > > since
> > > > > > > this
> > > > > > > > > mechanism requires a password in the
out_encryption.properties
> > > > file (and
> > > > > > > in
> > > > > > > > > the incoming properties file as well). Is there any way to
> > "hide"
> > > > this
> > > > > > > > > information? I guess it would make it hard to transition
my
> > > > artifact
> > > > > > > (web
> > > > > > > > > application) from one environment to the other (dev,
> > integration,
> > > > > > > testing,
> > > > > > > > > prod...)
> > > > > > > >
> > > > > > > > You can create your own crypto provider ( probably extending
> > Merlin)
> > > > > > > > which will decrypt paswords from config files during
loading.
> > > > > > > >
> > > > > > > > > and BTW, the example works perfectly ok.
> > > > > > > >
> > > > > > > > Thx :)
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > -----
> > > > > > > > When one of our products stops working, we'll blame another
> > vendor
> > > > > > > > within 24 hours.
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > >
> >
---------------------------------------------------------------------
> > > > > > > > To unsubscribe from this list please visit:
> > > > > > > >
> > > > > > > >
http://xircles.codehaus.org/manage_email
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > -----
> > > > > > When one of our products stops working, we'll blame another
vendor
> > > > > > within 24 hours.
> > > > > >
> > > > > >
> > > >
> >
---------------------------------------------------------------------
> > > > > > To unsubscribe from this list please visit:
> > > > > >
> > > > > > http://xircles.codehaus.org/manage_email
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > -----
> > > When one of our products stops working, we'll blame another vendor
> > > within 24 hours.
> > >
> > >
> >
---------------------------------------------------------------------
> > > To unsubscribe from this list please visit:
> > >
> > > http://xircles.codehaus.org/manage_email
> > >
> > >
> >
> >
>
>
> --
> -----
> When one of our products stops working, we'll blame another vendor
> within 24 hours.
>
>
---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
--
-----
When one of our products stops working, we'll blame another vendor
within 24 hours.
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
