|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
@Frédéric well we should be moving authentication credential storage to the credentials-plugin.
I was discussing with @Nicolas what needs to be done to get, e.g. subversion-plugin using the credentials-plugin. There is a number of things that I would like to see in terms of additions to the credentials-plugin API that should take place before wiring it up to more plugins.
The point of getting credentials 1.0 out was to let the API soak some more. After over a year of soaking I am mostly happy with the core of the API.
Where I feel there are gaps are with respect to grouping credentials and providing an easy way for consumers to retrieve credentials.
I am leaning towards adding Hamcrest matchers as a dependency, with methods for using those matchers to select a sub-set of credentials.
Additionally I am thinking of adding some grouping extension point to allow grouping related credentials together.
Finally, there needs to be a credential mapper extension point, thus you could have
A grouping that reflects, e.g. an Active Directory / LDAP domain.
Within the group a User/Password pair
A credential mapper from User/Password to SSH User/Password
A credential mapper from User/Password to HTTP(s) User/Password
A credential mapper from User/Password to SVNSERVE User/Password
Then the Credential consumer can ask for credentials within a Jenkins scope (i.e. specific job) for a specific user, against a specific host (which the grouping then matches) and for a specific protocol
The user, on the other hand, sees just the one credential in the one group, and changing that password updates all of that credential's use by Jenkins in one go.
The bits I need to refine are:
Then the final bits should actually be mostly trivial as there are very few authentication schemes that would need to be handled. (user/pass, user/key, client certificate. I think that is all)