Some more details, as it is a bit confusing:

The several points-of-interest that interact with this problem:
1) anonymous/unauthenticated hudson.
2) user authenticated via hudson.
3) hudson project SCM configured w/ credentials.
4) user SCM credentials different than both user authenticated via hudson or
hudson project SCM configuration.
5) pom.xml with credentials configured directly to devconnection.
6) If there is a maven settings.xml file involved (unsure....).

Looks like my present scenario, it is always using the hudson SCM configured
credentials instead of my hudson authenticated login, which in some cases may be
good, but not expected.

Overwriting the m2 release plugin to manually pass -Dusername/-Dpassword as part
of setGoal seems to support partial success, but that is for the last option
where it is always required to be entered.

NOTE: when testing this, need remember to clear out the release.properties file
in your project, otherwise may be inconsistent testing.

It looks like focusing on 4) as the overall/override option to always be used
for all scenarios might be best for a quick solution.

I'm trying to get my head around the usecases and if this needs a full UI.

1) audit (who performed the release)
recorded by hudson (see build started by xxx)
to record in the scm we could expose the logged in hudson user to the
environment and use it in the pom ${env.HUDSON_USER} in the release tag
(what would stop you creating a release manually?)

2) limit who can start a release.
should be done in the next release if you have matrix security.

3) use anon scm for hudson and a rw user for release
I can see this usecase - but I can't see it changing for each release.

For the above usecases, #3 is close, while #1 may be valid for some users,
others (like myself) keep the build server as simple as possible and rely on the
SCM and/or ticket trackers for auditing.

Use case 3, and the above information, I did run into a problem that may go
deeper than expected:
--------------------
Doing some more digging, I think part of the challenge for the problem below
might lie within the SCM (in this case, Subversion 1.4.6 using svn+ssh).

from the commandline if I did something like this, emulating passing an explicit
user and instead of the maven-release 'commit' just doing list:
>svn --username asdf list

it ignores the --username and instead asks for the hudson-SCM configured user's
password, since that is what was used to originally check it out--
>hudson-builder@svn.java.net password:
>hudson-builder@svn.java.net password:
>hudson-builder@svn.java.net password:

Unfortunately, this goes in the SVN realm, now several layers deep -
hudson/maven/maven-release-plugin/SCM/subversion. So the root challenge of
explicitly passing a username/password for the SCM Tagging becomes problematic.

One potential solution is to do a full workspace 'wipe out' and re-checking out
as the explicit user/password of the person doing the release.

workaround –
1. code
2. hudson SCM and pom SCM have different 'servers'.

code: you can use the setGoal(" -Dusername=asdf -Dpassword=asdf "); to
explicitly pass the username and password to Maven. This WILL send the password
as cleartext to the console log.

SCM: Have the Hudson SCM configuration for the project use either the FQDN or a
short version of the server, and the opposite for the pom.xml (or, if you want
to be tricky, setup a host file to have a local DNS name for the server on
Hudson, but have the pom point to the real dns name).

hudson: scmserver/trunk/....
pom.xml developerConnection: scmserver.java.net/trunk...
pom.xml tagBase: scmserver.java.net/trunk....

Where the two server strings are different, it won't use the hudson-saved SCM
credentials and instead use the credentials passed to Maven.

This is definitely not recommended as a normal practice, just re-documenting the
discussions.

binarymonk01, it would be nice if "2) user authenticated via hudson" is
supported. Hudson has asked my credentials when using ssh+svn repository and I
would like these credentials be re-used when release process is performed. Right
now for svn+ssh I had to setup RSA-key-authentication to allow passwordless access.

see JENKINS-5295