Announcement Announcement Module
Collapse
No announcement yet.
Spring Security integration - semi-anonymous users Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring Security integration - semi-anonymous users

    Hi,

    I'm using BlazeDS Integration RC1 and Security 2.0.4.

    In my app I need to have two types of users - 'standard' users, which login with a username & password, backed by a DAO provider.
    The other type are semi-anonymous users. They are required to enter just a name (no password) to login. Their login is always successful, provided they have supplied a name (nick).

    My 'standard' users login using ChannelSet.login, as per the documentation.
    I want the semi-anonumous users to also go through some kind of an authentication process, I'm just not sure how to implement it.

    My most developed direction is using anonymous provider, with a twist - instead of using a fixed user name, like in AnonymousProcessingFilter line 77, I'll take the user name from the request, and in this way I'll get an anonymous user, but with his real name.

    I think this should not be implemented using a call to channelSet.login, but rather to an applicative login method.

    One issue remains - How to extract the username from the request. Is the only solution implementing some sort of a AnonymousMessageInterceptor, which will be a replica of AnonymousProcessingFilter, but for flex ?

    Any thoughts on the subject will be greatly appreciated.

    Ido

  • #2
    Using an interceptor approach doesn't really seem necessary based on the way I'm reading it. The point of the AnonymousProcessingFilter is that the user never has to enter anything and gets automatically authenticated in a sense.

    I assume the reason you don't want to use ChannelSet.login is so that you can differentiate between the normal login process and this other process?

    Why not just implement a remoting destination that exposes a service that takes the username as a parameter and invoke it directly?

    Comment


    • #3
      Basically, if I understand you correctly, you're asking me why am I trying to 'force' authentication for my special users.

      The answer is I'm not 100% sure I need it, but I wanted to have know that all of my users are authenticated, in a common way. Having SecurityContextHolder.getContext().getAuthenticati on().getName() return the user name, no matter what kind the user is.
      Not sure that's very important.

      Anyway - can you explain more about the MessageInterector problem you mentioned? why is this not a way to go, in your opinion ?

      Thanks for your help,
      Ido

      Comment


      • #4
        Originally posted by idotzang View Post
        Having SecurityContextHolder.getContext().getAuthenticati on().getName() return the user name, no matter what kind the user is.
        Right, so making a remoting call to a custom service that sets up the SecurityContext would achieve this.

        Originally posted by idotzang View Post
        Anyway - can you explain more about the MessageInterector problem you mentioned? why is this not a way to go, in your opinion ?
        It just sounds like you're going to be making multiple requests anyway...one to authenticate, and then further requests to do everything else (typical remoting calls, etc)...so using MessageInterceptor doesn't really buy you anything. Why would you need to intercept every request for this? Just set the Authentication object representing the semi-anonymous user in the SecurityContext once and you're done.

        Comment


        • #5
          Sounds reasonable.

          Thanks, I think I'll go down your suggested path.
          I'll post anything interesting here.

          Ido.

          Comment

          Working...
          X