What if instead of writing the user and pass on the properties file we
delegate that task to a specific class? That will give end users more
flexibility as to where to get the data from (could be .properties, xml,
database, system properties.....).
I also think it would be a good idea that the XFire class be wired with
Spring, and so does this new class required to get the user / pass
encryption data.
On 3/23/07, Tomek Sztelak <[EMAIL PROTECTED]> wrote:
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
