New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How does authentication work? #462

Closed
Kricket opened this Issue Mar 31, 2015 · 3 comments

Comments

Projects
None yet
2 participants
@Kricket

Kricket commented Mar 31, 2015

After reading the documentation, I see that it's possible to check that a "username" key has been defined in the Context in order to allow or deny access to a resource. However, there is nothing to indicate how this "username" got there.

Could the documentation be improved so that it provides a more complete explanation of how this might be used? How would a user log on/log off? How would a wisdom component check a password, and what would it do in the event of success/failure? Is the "context" something that a malicious user could hack, by injecting a random username?

@cescoffier

This comment has been minimized.

Show comment
Hide comment
@cescoffier

cescoffier Mar 31, 2015

Member

Hello,

2015-03-31 13:40 GMT+02:00 Kricket notifications@github.com:

After reading the documentation, I see that it's possible to check that a
"username" key has been defined in the Context in order to allow or deny
access to a resource. However, there is nothing to indicate how this
"username" got there.

The username is set by an interceptor (
https://github.com/wisdom-framework/wisdom/blob/master/core/router/src/main/java/org/wisdom/router/security/AuthenticationInterceptor.java).
This filter looks for a Authenticator service to authenticate the user such
as the Monitor Authenticator (
https://github.com/wisdom-framework/wisdom/blob/master/extensions/wisdom-monitor/src/main/java/org/wisdom/monitor/extensions/security/MonitorAuthenticator.java).
The Context.getUserName is independent of the authentication mechanism, and
is just here to let controller retrieve it. It's not used to check whether
the request is authenticated or not.

Each authenticated action can define the name of the authenticator is want
to use. If this authenticator is not available, the action is rejected.

Could the documentation be improved so that it provides a more complete
explanation of how this might be used? How would a user log on/log off? How
would a wisdom component check a password, and what would it do in the
event of success/failure? Is the "context" something that a malicious user
could hack, by injecting a random username?

About the documentation, definitely. The current documentation is quite
succinct (
http://wisdom-framework.org/reference/0.8.0/index.html#_authentication).

The user login / logoff is not directly defined by the authenticator (just
checking whether a user is authenticated). So you need a 'controller'
handling this in a way the authenticator can understand.

For instance, in
https://github.com/wisdom-framework/wisdom/blob/master/extensions/wisdom-monitor/src/main/java/org/wisdom/monitor/MonitorCenter.java#L128
you have an action authenticating the user. It sets a variable in the
session. This variable is read by the monitor authenticator.

So, injecting a random username would not let him access to denied
resource, as, the check happen on all incoming request.

Cheers,

Clement


Reply to this email directly or view it on GitHub
#462.

Member

cescoffier commented Mar 31, 2015

Hello,

2015-03-31 13:40 GMT+02:00 Kricket notifications@github.com:

After reading the documentation, I see that it's possible to check that a
"username" key has been defined in the Context in order to allow or deny
access to a resource. However, there is nothing to indicate how this
"username" got there.

The username is set by an interceptor (
https://github.com/wisdom-framework/wisdom/blob/master/core/router/src/main/java/org/wisdom/router/security/AuthenticationInterceptor.java).
This filter looks for a Authenticator service to authenticate the user such
as the Monitor Authenticator (
https://github.com/wisdom-framework/wisdom/blob/master/extensions/wisdom-monitor/src/main/java/org/wisdom/monitor/extensions/security/MonitorAuthenticator.java).
The Context.getUserName is independent of the authentication mechanism, and
is just here to let controller retrieve it. It's not used to check whether
the request is authenticated or not.

Each authenticated action can define the name of the authenticator is want
to use. If this authenticator is not available, the action is rejected.

Could the documentation be improved so that it provides a more complete
explanation of how this might be used? How would a user log on/log off? How
would a wisdom component check a password, and what would it do in the
event of success/failure? Is the "context" something that a malicious user
could hack, by injecting a random username?

About the documentation, definitely. The current documentation is quite
succinct (
http://wisdom-framework.org/reference/0.8.0/index.html#_authentication).

The user login / logoff is not directly defined by the authenticator (just
checking whether a user is authenticated). So you need a 'controller'
handling this in a way the authenticator can understand.

For instance, in
https://github.com/wisdom-framework/wisdom/blob/master/extensions/wisdom-monitor/src/main/java/org/wisdom/monitor/MonitorCenter.java#L128
you have an action authenticating the user. It sets a variable in the
session. This variable is read by the monitor authenticator.

So, injecting a random username would not let him access to denied
resource, as, the check happen on all incoming request.

Cheers,

Clement


Reply to this email directly or view it on GitHub
#462.

@cescoffier cescoffier added the planned label Apr 2, 2015

@cescoffier

This comment has been minimized.

Show comment
Hide comment
@cescoffier

cescoffier Apr 2, 2015

Member

I will update the documentation with the content of my previous comment,

Member

cescoffier commented Apr 2, 2015

I will update the documentation with the content of my previous comment,

@cescoffier cescoffier added this to the 0.8.1 milestone Apr 2, 2015

@cescoffier cescoffier added ready and removed planned labels Apr 2, 2015

@cescoffier cescoffier self-assigned this Apr 2, 2015

@Kricket

This comment has been minimized.

Show comment
Hide comment
@Kricket

Kricket Apr 3, 2015

OK, thanks.

Kricket commented Apr 3, 2015

OK, thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment