This message really belongs on the users_at_subversion.apache.org list.
It's difficult to answer your question due to the wide variety of
setups that Subversion can be used with (multiple different servers
e.g. Apache [http], svnserve [svn and svn+ssh]) and clients (command
line client, TortioseSVN, SmartSVN etc...). All of which may have
varying levels of support for different authentication setups.
Unfortunately, you don't provide any details as to how you're using
Subversion today.
What I can tell you is that since Subversion is not in general a web
application, meaning the majority of the time Subversion is accessed
using clients specifically made for Subversion as opposed to general
purpose Web browsers (though some setups use HTTP to communicate). As
such it's not generally possible to use SSO setups that depend on
redirects (e.g. CAS) with Subversion.
If you're interested in using Subversion with Kerberos(GSSAPI) or SSPI
that is possible, though certainly not a trivial setup.
SSPI is mentioned in our FAQ: http://subversion.apache.org/faq.html#sspi
GSSAPI is mentioned in our SASL support notes:
http://svn.apache.org/repos/asf/subversion/trunk/notes/sasl.txt
However, much simpler setups can be achieved that use the same
username/password combinations with Subversion as with other services
by using things like LDAP.
Regarding response times to development requests, as you may be aware
Subversion is an open source project. We can't make any promises as
to how quickly a suggested feature might be implemented. However, as
an open source project we would welcome contributions of additional
functionality.
If all of this seems daunting to you I'd recommend that you work with
one of the several companies that provide support or consulting for
Subversion.
On Fri, Nov 2, 2012 at 1:59 PM, <Eduard.Perelman_at_ey.com> wrote:
>
> Hi,
>
> Our objective is to create an external single-sign-on (SSO) module to
> support login to the various applications we currently use. We are in the
> process of custom developing the SSO module in-house to support these
> multiple applications. This module will present a form to allow the user to
> type in the user name and a password and click Submit to authenticate. Upon
> successful authentication, against our ldap system, user's browser will be
> redirected to your application.
>
> What we need to understand from you is - how to best integrate with the
> external authentication/authorization module we are developing currently?
> What's your current default model of handling user authentication? Can your
> application support an external SSO component? This support would imply that
> the application can turn OFF its default authentication mode and can rely on
> this external SSO module to pass back a secure token. If you have a standard
> approach that we can follow, please provide the necessary details, including
> any open API's your application might provide for this purpose.
>
> Provided you don't support a more common approach (because we need to worry
> about 8 other in-scope applications working with each other based on this
> common SSO layer), how flexible/quick are you upon receiving our requirement
> to complete your own in-house custom development to align with our strategy?
>
> I'd appreciate if your initial response is handled via email and is sent
> back to us no later than Friday, November 9th, and then we'll look to
> schedule a follow-up call for any open questions during the week of November
> 12th.
>
> Thanks, Ed
> Eduard Perelman | Contractor | Assigned to: IT Services
> 200 Plaza Drive, Secaucus, NJ 07094, United States of America
> Office: +1 201 872 2215 | Cell: +1 917 306 8364 | eduard.perelman_at_ey.com
> Website: www.ey.com
> Thank you for considering the environmental impact of printing emails.
>
>
> Any U.S. tax advice contained in the body of this e-mail was not intended or
> written to be used, and cannot be used, by the recipient for the purpose of
> avoiding penalties that may be imposed under the Internal Revenue Code or
> applicable state or local tax law provisions.
> ________________________________________________________________________
> The information contained in this message may be privileged and confidential
> and protected from disclosure. If the reader of this message is not the
> intended recipient, or an employee or agent responsible for delivering this
> message to the intended recipient, you are hereby notified that any
> dissemination, distribution or copying of this communication is strictly
> prohibited. If you have received this communication in error, please notify
> us immediately by replying to the message and deleting it from your
> computer.
>
> Notice required by law: This e-mail may constitute an advertisement or
> solicitation under U.S. law, if its primary purpose is to advertise or
> promote a commercial product or service. You may choose not to receive
> advertising and promotional messages from Ernst & Young LLP (except for
> Ernst & Young Online and the ey.com website, which track e-mail preferences
> through a separate process) at this e-mail address by forwarding this
> message to no-more-mail_at_ey.com. If you do so, the sender of this message
> will be notified promptly. Our principal postal address is 5 Times Square,
> New York, NY 10036. Thank you. Ernst & Young LLP
Received on 2012-11-02 23:01:59 CET