I figured out the issue where it redirects to the unauthorized page. It was a bug that you would not believe. It was in my Hiberate DAO.
It was a DAO that queries a view. It was returning the same row over and over. I had to do a select new(v.username, v.privilege) from myview v in order to get it to work. Has anyone else ever encounted such a thing? ------ Original Message ------ Received: 07:33 PM EST, 03/05/2011 From: mangelo <[email protected]> To: [email protected] Subject: Re: Single Sign On (SSO), Spring, Hibernate Help. > Hey Les. Making great progress. Still working on the weekend though. > > I've written yet another filter that maybe we can add to the project. Its a > filter that I call 'any'. It will succeed if any of the roles are attached to > the subject: > > /** = any[role1 | role2 | role3] > > I'm having a strange problem elsewhere. When I refresh on a page, I always get > redirected to my unauthorizedURL page. Cant' figure out why this is happening. > Here is my filterChainDefinitions entry: > > /Document.faces = sso, edmsAuth, any[RECORDS_MANAGEMENT_ADMIN | > RECORDS_MANAGEMENT_ENTRY] > /DocumentSearch.faces = sso, edmsAuth, any[RECORDS_MANAGEMENT_ADMIN | > RECORDS_MANAGEMENT_ENTRY | RECORDS_MANAGEMENT_USER] > /FRCTool.faces = sso, edmsAuth, any[RECORDS_MANAGEMENT_ADMIN | > RECORDS_MANAGEMENT_ENTRY] > /LitigationManager.faces = sso, edmsAuth, any[RECORDS_MANAGEMENT_ADMIN | > RECORDS_MANAGEMENT_ENTRY] > /images/** = sso, edmsAuth > /resources/** = sso, edmsAuth > /templates/** = sso, edmsAuth > /unauthorized.faces = sso, edmsAuth > /** = sso, edmsAuth, any[RECORDS_MANAGEMENT_ADMIN | RECORDS_MANAGEMENT_ENTRY | > RECORDS_MANAGEMENT_USER] > > The /** entry I know is not safe, but I have it in there now to try and track > down where this issue may be coming from. Even with that entry I'm still > getting redirected. > > Any clue as to why this may be happening? > > > > ------ Original Message ------ > Received: 02:34 PM EST, 03/04/2011 > From: "Les Hazlewood-2 [via Shiro Developer]" > <[email protected]> > To: mangelo <[email protected]> > Subject: Re: Single Sign On (SSO), Spring, Hibernate Help. > > > > > > > Hi Mike, > > > > As Jared said, I would probably implement this as a filter as well. > > Here's how I might do it (this is off the top of my head, so if it is > > confusing, please let us know). > > > > 1. Create an implementation of the AuthenticationToken interface that > > will hold your Oracle SSO ID (or whatever else comes in the headers). > > Maybe call it TrustedAuthenticationToken or > > TrustedOracleSsoAuthenticationToken > > > > 2. Create a filter that extends > > org.apache.shiro.web.filter.authc.AuthenticatingFilter and override > > the 'createToken(request,response)' method. In this method, return an > > instance of your TrustedAuthenticationToken that you construct based > > on the request/response pair. You can look at the existing > > org.apache.shiro.web.filter.authc.BasicHttpAuthenticationFilter source > > code to give you ideas - it does very similar things. > > > > 3. In your filter, override the 'onAccessDenied(request,response)' > > method to do almost exactly what the BasicHttpAuthenticationFilter > > does. In this method you basically determine "should this request > > perform a login? If so, call executeLogin(request,response). If not, > > prevent the request from going through". See the > > BasicHttpAuthenticationFilter's implementation of that method for an > > example. > > > > 4. Create a TrustedOracleSsoRealm implementation that extends > > AuthorizingRealm. In your constructor, automatically call the > > following: > > > > setCredentialsMatcher(new AllowAllCredentialsMatcher()); > > setAuthenticationTokenClass(TrustedAuthenticationToken.class); > > > > The first line ensures that credentials matching won't be performed > > when a Realm functions during a login attempt (this is because you > > trust that Oracle already performed the login credentials matching on > > its side). The second line ensures that the realm won't participate > > in any logins except the Oracle-related ones initiated by your filter. > > > > (specify this realm in your Shiro SecurityManager config of course - > > shiro.ini, spring, etc). > > > > 5. In that Realm's doGetAuthenticationInfo implementation, cast the > > token argument to your TrustedAuthenticationToken class. Obtain your > > oracle SSO token, and from that return the corresponding principals > > and credentials (usually in the form of a SimpleAuthenticationInfo or > > SimpleAccount instance). > > > > 6. You an also implement doGetAuthorizationInfo to obtain > > roles/permissions. In this method call the 'getAvailablePrincipal' > > method to obtain the first principal in the principal collection > > associated with that realm only. This is usually your 'primary > > identifier' for that subject, and from it you can obtain the roles and > > permissions and return an instance of AuthorizationInfo. > > > > 7. Optional - enable caching to ensure that authorization lookups and > > checks remain efficient. Configure Shiro's securityManager to use a > > cacheManager, e.g. in shiro.ini: securityManager.cacheManager = > > $myCacheManager > > > > > > Obviously it would be nice if Shiro had an OracleSsoRealm and > > corresponding Filter already in place. If you're willing to donate > > your implementation to the ASF, we'd appreciate it! Then other people > > can benefit from this as well. > > > > Anyway, I hope that helps - let us know how it goes. > > > > Best, > > > > -- > > Les Hazlewood > > Founder, Katasoft, Inc. > > Application Security Products & Professional Apache Shiro Support and > Training: > > http://www.katasoft.com > > > > On Fri, Mar 4, 2011 at 10:01 AM, mangelo <[email protected]> wrote: > > > I appreciate the help, but I am so lost that I have no idea where to > turn. > > > > > > My scenario is like this: Users are already authenticated and as a result > > > their user-id is in the HttpServletRequest header. I thought I was > supposed to > > > use the Realm to load their roles, permissions, etc, but it looks like > some of > > > what is in the Realm is duplicated in the AuthenitcatingFilter. > > > > > > Once I get the Subject loaded up with their roles and permissions all is > well > > > and good. Why I could not use Spring security is the user is able to > change > > > their 'region' which comes with it a new set of permissions. I need for > Shiro > > > to load up these new permissions so that they can be checked for later. > > > > > > And now, I'm still staring at a blank wall and security was supposed to > be > > > done this week. > > > > > > Mike > > > > > > ------ Original Message ------ > > > Received: > > > From: "Jared Bunting [via Shiro Developer]" > > > <[email protected]> > > > To: mangelo <[email protected]> > > > Subject: Re: Single Sign On (SSO), Spring, Hibernate Help. > > > > > >> > > >> > > >> On 03/04/2011 09:33 AM, mangelo wrote: > > >> > I am brand new to Shiro. Just found it last night. I am very > encouraged > > > from > > >> > what I've read so far. My security requirements seem to be too much > for > > >> > Spring Security. I am confident that Shiro can handle them given the > > >> > flexibility. > > >> > > > >> > The only problem is that I don't know how quite to get started. I've > > > found > > >> > the Spring samples and how to get set up. My problem is the users of > my > > > app > > >> > are already authenticated by Oracle SSO. The username is in the > request > > >> > header. > > >> > > > >> > How do I get it out of the request header and into Shiro? Where would > I > > > put > > >> > such code? > > >> > > >> This should go into a filter. You likely want to extend > > >> AuthenticatingFilter - look at the BasicHttpAuthenticationFilter for an > > >> example that uses headers. > > >> > > >> Basically, your filter should pack up the header value in an > > >> AuthenticationToken. Shiro will pass this AuthenticationToken to your > > >> Realm. > > >> > > >> > > > >> > I have based my Realm from the SampleRealm class. Should I always > return > > >> > 'false' from the supports method? Should I return > > > SimpleAuthenticationInfo() > > >> > with an empty string as the password? > > >> > > >> I would say yes. In addition, accept the AuthenticationToken type that > > >> you created in your filter. > > >> > > >> > > > >> > If there is a more complete example that would help out a lot. I feel > > > like > > >> > I've hit a brick wall. > > >> > > > >> > TIA. > > >> > > > >> > MIke. > > >> > > > >> > -- > > >> > View this message in context: > > > > http://shiro-developer.582600.n2.nabble.com/Single-Sign-On-SSO-Spring-Hibernate-Help-tp6088874p6088874.html > > >> > Sent from the Shiro Developer mailing list archive at Nabble.com. > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> If you reply to this email, your message will be added to the discussion > > > below: > > >> > > > > http://shiro-developer.582600.n2.nabble.com/Single-Sign-On-SSO-Spring-Hibernate-Help-tp6088874p6089122.html > > >> > > >> To unsubscribe from Single Sign On (SSO), Spring, Hibernate Help., visit > > > > http://shiro-developer.582600.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=6088874&code=bWlrZWFuZ2Vsb0B1c2EubmV0fDYwODg4NzR8LTE1NDY4NDI3NDY= > > > > > > _______________________________________________ > > If you reply to this email, your message will be added to the discussion > below: > > > http://shiro-developer.582600.n2.nabble.com/Single-Sign-On-SSO-Spring-Hibernate-Help-tp6088874p6089768.html > > > > To unsubscribe from Single Sign On (SSO), Spring, Hibernate Help., visit > http://shiro-developer.582600.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=6088874&code=bWlrZWFuZ2Vsb0B1c2EubmV0fDYwODg4NzR8LTE1NDY4NDI3NDY= > > > > > -- > View this message in context: http://shiro-developer.582600.n2.nabble.com/Single-Sign-On-SSO-Spring-Hibernate-Help-tp6088874p6093136.html > Sent from the Shiro Developer mailing list archive at Nabble.com.
