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=
