History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: JRA-5208
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Bob Vandehey
Votes: 1
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
JIRA

Authenticator interface should support authenticating tokens

Created: 11/Nov/04 12:47 PM   Updated: 06/Mar/06 04:01 PM
Component/s: Permissions Security
Affects Version/s: 3.0.2
Fix Version/s: None

Time Tracking:
Not Specified

Issue Links:
Reference
 

Participants: Bob Vandehey, Jeff Turner [Atlassian], Robert Greig and Scott Farquhar [Atlassian]
Since last comment: 191 weeks, 5 days ago
Labels:


 Description  « Hide
Currently, the RPC/SOAP interface allows a user to remotely login and returns a token upon successful authentication. This token is issued by the TokenManager plugin module. Unfortunately, this token is only useful for accessing the RPC/SOAP interface. It would be useful to also use this token to log into Jira's web interface. I have written a LoginFilter that does this. Unfortuately, because the Authenticator.Login() method requires a username/password to login, it prevents me from using the following code since I don't have a password any longer, only a username:

securityConfig.getAuthenticator().login(request, response, user.getName(), "password", persistentLogin);

Ideally, the TokenManager would depend on the Authenticator to issue the token (TokenManager would no longer be needed then). Then, the LoginFilter could login the user with a method similar to:

securityConfig.getAuthenticator().tokenLogin(request, response, token, persistentLogin);

Because this capability isn't available, I had to write code like the following in my LoginFilter:

TokenManager tokenManager = this.getTokenManager();
if(null != tokenManager)
{
user = tokenManager.retrieveUser(token);
if(null != user)

{ request.getSession().setAttribute(com.atlassian.seraph.auth.DefaultAuthenticator.LOGGED_IN_KEY, user); request.getSession().setAttribute(com.atlassian.seraph.auth.DefaultAuthenticator.LOGGED_OUT_KEY, null); }

}

This is a hack since it depends on Jira using the default authenticator as well as requiring knowledge of the internal workings of the class.



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Jeff Turner [Atlassian] - 11/Nov/04 07:27 PM
Hi,

If you are checking a token to determine whether someone should be regarded as logged in, then you should have a look at:

http://opensource.atlassian.com/seraph/sso.html

It describes how to implement a replacement for DefaultAuthenticator that returns a User if a token (from a cookie) was found, and sets the session attributes just as you do.


Robert Greig - 18/Nov/04 05:12 AM
There is a general flaw in osuer (which isn't obvious admittedly).

It assumes you know the username up front because UserManager does not have an authenticate method (you look up a User object then call authenticate on that).

This is wrong IMO. With certain schemes (most notably Kerberos) you have an opaque token and you do not know the username until you have acutally authenticated (you handshake with the Kerberos TGS to find out what the user principal is).

I think the underlying problem is that mixing profile lookup with authentication is wrong.

On a slightly unrelated topic, I also don't understand why CredentialsProvider etc are subinterfaces of UserProvider. It means you have to implement a lot of methods that are entirely irrelevant (e.g. store() etc.).


Scott Farquhar [Atlassian] - 18/Nov/04 11:29 PM
Robert,

You don't neccessarily need to authenticate with OSUser - you can just authenticate in Seraph. If you write your own Seraph provider, then you should be able to authenticate any way you want to.

Whilst I agree that OSUser isn't neccessarily the best API, and we are moving away from it, I think you can achieve what you are after.