Announcement Announcement Module
Collapse
No announcement yet.
SSO, RequiresAuth, direct urls -- need help Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • SSO, RequiresAuth, direct urls -- need help

    Hey all,

    I have an app with mixed authentication (Form and Siteminder). My question is with the requires authentication method and siteminder.

    Can acegi (maybe i broke default behavior) be setup to allow initial requests of siteminder auth'd users to any url, not just the targetURL, and still create authentication object? To clarify my issue, i would like to allow siteminder users to be able to use direct url's like ../account or ../info and not just /home but still have acegi recognize that they are siteminder users and create there person object/authentication object on first request. It seems to only want to do authentications on j_security_check and on defaultTargetUrl and if any other url comes in it doesnt create the objects even though siteminder users are always authed. It then bounces them to an error page (form login page which is obviously wrong).

    I have tried overriding SiteminderAuthenticationProcessingFilter.requiresA uthentication but the effects are very strange. Is this the right place to try and make it happen?


    thanks,
    Adrian

  • #2
    Found a JIRA, but i thought there was a workaround.. maybe not..

    http://jira.springframework.org/brow...s:all-tabpanel

    Comment


    • #3
      I'm not really very familiar with siteminder, but I think the current implementation could be simplified substantially. It has a built in option to use a login form which I think over complicates things too. There are a few siteminder issues open, but there hasn't been any work done on the code for some time.

      If you are able to assume that all requests have been authenticated by siteminder, then it shouldn't be too difficult to write a simple filter which pulls out the appropriate header information and generates an authentication token from it. Appropriate behaviour might be to only do this if the current authentication object is null. Then obtain the user name and load their authorities. If an authentication token is already present then do nothing (to avoid loading user data on every request).

      Comment


      • #4
        that is exactly what i was trying to accomplish but i was going about it in a bad way. I will try to implement what you are describing.

        thanks.

        Comment

        Working...
        X