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.

over http(s), i'll be glad to prefer it

, 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 http://tomcat.apache.org/tomcat-5.5-doc/config/valve.html#Single_Sign_On_Va… ). as based account, this 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 > > > > > > 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 That's access david.delbecq(a)meteo.be> would how -- 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