On Wed, Jun 20, 2012 at 9:54 AM, David Delbecq <david.delbecq(a)meteo.be>wrote;wrote:
Hello all,
if someone has access to restricted xwiki area (escalation or any other
way), this someone could just create a javascript wiki page using
skinextension, that will grab password from login form and send it anywhere
in the wiki for later retrieval. So i don't feel like i create any security
hole there.
If a user has access to the server, he could just feed
it with it's own
XwikiAuthService or LDAP server that record password before forwarding to
real ldap server.
Our company has no kerberos, ntlm, etc server running, so i can't easily
use such solution. Removing password for authentication on background
service is no option either, as wiki will be a portal to those services,
but some operation still need user to navigate to those services. For
example, a webdav service: listing in xwiki page of a folder content should
be done using xwiki current user's priviledges (xwiki is the http client),
but when user want to retrieve a specific file or want to mount the webdav
service on his workstation, he access the webdav service directly.
Using "unsecure" password is no option either, all users in the company
are supposed to use same password for all services (ldap central
authentication).
Keep in mind, the only things i have write access to is a few jboss
servers, their configuration, and the webapp running on them. All
applications (except unfortunately xwiki) use container based
authentication.
I already replied to say XWiki supports container based authentication
throught the AppServerTrusted authenticator. What's missing ?
If someone has doc on how to forward credentials from one webapp to another
If you use container based authentication, I imagine you should be able to
copy over the authorization header from the originating request to the one
you create in your HTTP client (since I understand you are making HTTP
calls to the tiers apps).
Jerome
, but the only documentions on jboss/sso i have found
so far assume all
request come from browser! Kerberos or similar service, while a good
solution as supported by jboss (but "experimental" in xwiki), afaik,
requires to add additionnal schemas to ldap so tickets can be stored. And i
know from experience that if i request such service installed and
configured on our central server, i am not sure to get them before next
year.
I understand your concerns, i do not like the idea of storing password in
memory. But i see no viable solution for now to have our xwiki be a portal
to various services on behalf of it's current user.
Thank you
David Delbecq
----- Mail original -----
De: "Jerome Velociter" <jerome(a)winesquare.net>
À: "XWiki Developers" <devs(a)xwiki.org>
Envoyé: Mardi 19 Juin 2012 15:16:54
Objet: Re: [xwiki-devs] Access password of current user
On Tue, Jun 19, 2012 at 2:58 PM, David Delbecq <david.delbecq(a)meteo.be
wrote:
Hello,
unfortunately, we don't have any explicit sso service currently running.
In the past, we simply asked the container (tomcat) to manage
authentication of users for all our webapplication and we followed tomcat
directions on how to share principal for all applications (
http://tomcat.apache.org/tomcat-5.5-doc/config/valve.html#Single_Sign_On_Va…
).
This works well when all application use
container authentication and the
only client is the user's web browser. Unfortunately, things will change
as
we will base our intranet on xwiki instead of
having separate spread
applications the user needs to connect to. This mean the web server (now
jboss) will be the http client of all other services, and thus realm
based
sso won't work. For some of those service we
use generic technical
account,
so no problem, we just store the password. But
for some other, we must
transmit the user / password of current xwiki user so xwiki is seen by
this
service as this user.
And none of those behind the scene applications were ever configured to
use kerberos or anything alike. Moreover, i would like to avoid the
nightmare of maintaining such a service when simply forwaring user / pass
to next service would solve my problems :)
Storing plain-text user password is never a good idea, be it on the
database, filesystem or in memory.
If you store passwords in the session, some XWiki applications could read
them, someone in your organization with programming access level can access
them, a hacker that escalate to have access to the machine or to
programming rights in the application can read them, etc.
Jerome
>
> Regards,
> David Delbecq
>
> ----- Mail original -----
>
> De: "Guillaume Lerouge" <guillaume(a)xwiki.com>
> À: "XWiki Developers" <devs(a)xwiki.org>
> Envoyé: Mardi 19 Juin 2012 14:40:16
> Objet: Re: [xwiki-devs] Access password of current user
>
> Hi David,
>
> which SSO service dou you use internally? XWiki authenticators already
> exist for CAS, Kerberos and NTLM, maybe you could draw inspiration from
> them.
>
> Guillaume
>
> On Tue, Jun 19, 2012 at 1:54 PM, David Delbecq <david.delbecq(a)meteo.be
>
wrote:
>
> >
> > Hello,
> >
> > I was hoping that somehow, when submitted via the form, password gets
> > recorded until the end of the session. We can't afford, for the sake of
> > user experience, to ask password every time user need to access a
hidden
> system he is not even supposed to know is
separate from the wiki.
That's
> why we are writing some macro / components
so that it's xwiki that
access
those
system for him. This include various webservices, a documents
storage
and so on. We try to keep a single sign on
policy. Of course, i don't
want
> user password stored anywhere on disks, but keeping it in user session
> seems a good trade-of for me.
>
> I plan thus to create my onw xwikiauthservice that delegates to ldap
> service and store this in user session.
>
>
> ----- Mail original -----
>
> De: "Jerome Velociter" <jerome(a)winesquare.net>
> À: "XWiki Developers" <devs(a)xwiki.org>
> Envoyé: Mardi 19 Juin 2012 11:53:42
> Objet: Re: [xwiki-devs] Access password of current user
>
> Hi,
>
> Fortunately, you can't. You can only access/verify a hashed version of
> the password.
>
> Note that asking for a password again is not necessarily a bad UX,
> especially if it is to allow access to a sensitive area/operation.
>
> Cheers,
> Jerome.
>
> On Tue, Jun 19, 2012 at 11:39 AM, David Delbecq <
david.delbecq(a)meteo.be>
> wrote:
> >
> > Hello,
> >
> > i am writing a component that need a password. Because this password
> will be the same for current user as the one he used to log-in, it
would
> make for crappy interface ot ask it again to
user. So i need to know
how
my
component or a groovy script can access the
username / password of
current
logged-in user.
Thank you.
David Delbecq
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs