Maven 2 & 3

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

Details

  • Type: New Feature New Feature
  • Status: Open Open
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: Artifacts and Repositories, Settings
  • Labels:
    None
  • Complexity:
    Intermediate
  • Number of attachments :
    1

Description

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).

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
David Boden added a comment -

By the way, if someone with experience of developing Maven is happy to point me to the right place (class) to build this feature in then I'd be happy to build the feature, add unit tests, test with my real-life scenario here then produce a patch to be committed (onto Maven 3).

Show
David Boden added a comment - By the way, if someone with experience of developing Maven is happy to point me to the right place (class) to build this feature in then I'd be happy to build the feature, add unit tests, test with my real-life scenario here then produce a patch to be committed (onto Maven 3).
Hide
Permalink
David Boden added a comment -

I've done some investigation. The relevant class is in the artifact manager project and is called WagonManager. The DefaultWagonManager implementation is injected by Plexus.

The WagonManager interface contains definitions for methods that I want to modify the implementation of:

  • addConfiguration(String repositoryId, Xpp3Dom configuration) - Change to detect a <singleSignOn>com.custom.login.CustomLoginContext</singleSignOn> tag under the <server/> definition, put there instead of username and password. The classname in the <singleSignOn/> tag would implement javax.security.auth.login.LoginContext.
    In the case of single sign on, I can make the addConfiguration method log the user in using the LoginContext and then call the following method with the username and password:
  • addAuthenticationInfo(String repositoryId, String username, String password, String privateKey, String passphrase)
    The addAuthenicationInfo and the getAuthenticationInfo methods can probably remain as they are.

So, I'm now trying to weigh up what's involved in replacing the injection of DefaultWagonManager with a subclass; SingleSignOnWagonManager. Judging by the fact that plexus.xml is already present in the MAVEN_HOME/lib/maven-2.2.1-uber.jar under META-INF/plexus and you can only have one plexus.xml I don't think it's going to be possible to customise Maven 2.2.1. Instead, it looks like I'm going to have to do a checkout of the whole Maven project, make my changes then rebuild Maven 2.2.1.x. If I'm forced to go along this route, I'll submit a patch to DefaultWagonManager rather than creating a subclass.

Show
David Boden added a comment - I've done some investigation. The relevant class is in the artifact manager project and is called WagonManager. The DefaultWagonManager implementation is injected by Plexus. The WagonManager interface contains definitions for methods that I want to modify the implementation of:
  • addConfiguration(String repositoryId, Xpp3Dom configuration) - Change to detect a <singleSignOn>com.custom.login.CustomLoginContext</singleSignOn> tag under the <server/> definition, put there instead of username and password. The classname in the <singleSignOn/> tag would implement javax.security.auth.login.LoginContext. In the case of single sign on, I can make the addConfiguration method log the user in using the LoginContext and then call the following method with the username and password:
  • addAuthenticationInfo(String repositoryId, String username, String password, String privateKey, String passphrase) The addAuthenicationInfo and the getAuthenticationInfo methods can probably remain as they are.
So, I'm now trying to weigh up what's involved in replacing the injection of DefaultWagonManager with a subclass; SingleSignOnWagonManager. Judging by the fact that plexus.xml is already present in the MAVEN_HOME/lib/maven-2.2.1-uber.jar under META-INF/plexus and you can only have one plexus.xml I don't think it's going to be possible to customise Maven 2.2.1. Instead, it looks like I'm going to have to do a checkout of the whole Maven project, make my changes then rebuild Maven 2.2.1.x. If I'm forced to go along this route, I'll submit a patch to DefaultWagonManager rather than creating a subclass.
Hide
Permalink
David Boden added a comment -

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.

Show
David Boden added a comment - 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.
Hide
Permalink
David Boden added a comment - - edited

I raised https://issues.sonatype.org/browse/AETHER-54 but have asked for it to be closed as it was a red-herring. No changes are required to Aether to get this to work, only changes to Maven and Wagon are required.

At this stage, it's not straightforward to get deployment to work using single sign on. The current maven-deploy-plugin is using the old-style compatibility layer rather than using the Aether method. So, it's worth waiting until the deploy plugin is using the newer Aether APIs before trying to get single sign on to work.

Show
David Boden added a comment - - edited I raised https://issues.sonatype.org/browse/AETHER-54 but have asked for it to be closed as it was a red-herring. No changes are required to Aether to get this to work, only changes to Maven and Wagon are required. At this stage, it's not straightforward to get deployment to work using single sign on. The current maven-deploy-plugin is using the old-style compatibility layer rather than using the Aether method. So, it's worth waiting until the deploy plugin is using the newer Aether APIs before trying to get single sign on to work.
Hide
Permalink
Anders Hammar added a comment -

I believe it could take a while until the m-deploy-plugin uses the Aether API directly, as that would make it incompatible with Maven 2.x. However, you should create a ticket on that plugin to increase the likelihood. Maybe there could be a 3.x branch in the same manner as one exists for m-site-plugin.

Show
Anders Hammar added a comment - I believe it could take a while until the m-deploy-plugin uses the Aether API directly, as that would make it incompatible with Maven 2.x. However, you should create a ticket on that plugin to increase the likelihood. Maybe there could be a 3.x branch in the same manner as one exists for m-site-plugin.

People

Vote (2)
Watch (4)

Dates

  • Created:
    Updated:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.