[jira] Commented: (MNG-4602) Allow pluggable authentication (using JAAS ?) so that the username and password to connect to a deployment repository can be generated by a Single Sign On-enabled client

["David Boden (JIRA)" <ji...@codehaus.org>]

    [ http://jira.codehaus.org/browse/MNG-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249018#action_249018 ] 

David Boden commented on MNG-4602:
----------------------------------

It's all changed in Maven 3 with the introduction of Aether for repository management. The fix that I mentioned above isn't strategic for Maven 3 and, because we've already upgraded to Maven 3, I propose to fix it in a different way. In Maven 3 the server authentication details are read from settings.xml in:

Project: maven-core Method: org.apache.maven.DefaultMaven.newRepositorySession( MavenExecutionRequest request )

To get the LoginContext or CallbackHandler configuration into settings.xml under the <server/> tag, I'd need to create a new version of: http://maven.apache.org/xsd/settings-1.0.0.xsd As a quick-fix, I could just add the configuration to the <configuration/> tag under <server/>. It would be a better change to add the CallbackHandler configuration to the Authentication class. That way, the CallbackHandler could be used only when authentication is required. If I make a call to the CallbackHandler within newRepositorySession then I'll have to call every configured callback handler and generate a username and password. More efficient to leave the call until later so that only the server definitions that are being used result in a CallbackHandler call. That would require changing the org.sonatype.aether.repository.Authentication class in the aether-api module.

I'll then have to work out (probably by using a debugger) where the Authentication.getUsername() is called and see how many places need to be upgraded to support a call out to a CallbackHandler.

> Allow pluggable authentication (using JAAS ?) so that the username and password to connect to a deployment repository can be generated by a Single Sign On-enabled client
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: MNG-4602
>                 URL: http://jira.codehaus.org/browse/MNG-4602
>             Project: Maven 2 & 3
>          Issue Type: New Feature
>          Components: Artifacts and Repositories, Settings
>            Reporter: David Boden
>            Priority: Minor
>
> The username and password used to authenticate with the remote repository during deployment are stored in the user's settings.xml under the <servers/> structure. This structure allows a username and password to be specified, or for a .ssh private key to be specified.
> It does not allow for pluggable single sign on, where a Java module (perhaps a JAAS LoginModule) is available on the client to generate a token in place of a password. Many corporates use this technique for other web applications, generating an LDAP token from the user's PC and verifying it against an LDAP server on the server side. It adds security by removing the need to pass the user's password over the wire.
> This Jira is a request for a pluggable entry point for this single sign on module, perhaps by specifying a class name in the <server/> structure or by setting a system property. The solution could either define a new interface which Authentication Providers must implement or can use existing interfaces from JAAS, (Http) Authenticator or other frameworks.
> Please feel free to move this item to the "Maven Wagon" component if you feel that's the best place to implement the feature. Alternatively, please also feel free to move to the generic "Maven 2&3" component if you think that the feature has wider scope than just deployment; perhaps to also authenticate using Single Sign On with an internal company's repository when *downloading* artifacts (as well as uploading).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira