On Sat, Mar 28, 2009 at 8:10 PM, Daniel Beatty <[email protected]> wrote: > Greetings Joe, > Any parsing on that string? Does it contain information as to what "realm" > or authority granted the ticket? > > In my case, I am trying to use it similar to a UID in establishing a > standard set of permissions in my app(s). Naturally, identifying groups > would be nice, too. I am not sure how to approach this topic. But my > initial guesses would say to look up the LDAP information for participating > institutions in my "federation" and determine group and user permissions > accordingly. >
You simply need to know what apache headers that apache module sets, such as REMOTE_USER, and query for it as I've shown. a quick google showed the possible attributes in example code: http://shib.kuleuven.be/download/sp/test_scripts/shibenv.ssi.txt TTP_SHIB_APPLICATION_ID : <i><!--#echo var="HTTP_SHIB_APPLICATION_ID"--></i> HTTP_SHIB_IDENTITY_PROVIDER : <i><!--#echo var="HTTP_SHIB_IDENTITY_PROVIDER"--></i> HTTP_SHIB_PERSON_UID : <i><!--#echo var="HTTP_SHIB_PERSON_UID"--></i> HTTP_SHIB_PERSON_COMMONNAME : <i><!--#echo var="HTTP_SHIB_PERSON_COMMONNAME"--></i> HTTP_SHIB_PERSON_MAIL : <i><!--#echo var="HTTP_SHIB_PERSON_MAIL"--></i> HTTP_SHIB_PERSON_TELEPHONENUMBER : <i><!--#echo var="HTTP_SHIB_PERSON_TELEPHONENUMBER"--></i> HTTP_SHIB_EP_SCOPEDAFFILIATION : <i><!--#echo var="HTTP_SHIB_EP_SCOPEDAFFILIATION"--></i> [scope is usually checked] HTTP_SHIB_EP_UNSCOPEDAFFILITATION : <i><!--#echo var="HTTP_SHIB_EP_UNSCOPEDAFFILIATION"--></i> HTTP_SHIB_KUL_OUNUMBER : <i><!--#echo var="HTTP_SHIB_KUL_OUNUMBER"--></i> HTTP_SHIB_KUL_PRIMOUNUMBER : <i><!--#echo var="HTTP_SHIB_KUL_PRIMOUNUMBER"--></i> REMOTE_USER : <i><!--#echo var="REMOTE_USER"--></i> > Unfortunately, this one of those areas where security can high-jack a > project, even a dissertation with all the academic freedom in the world. > > Later, > Dan > > > > On Mar 28, 2009, at 12:55 PM, Joe Little wrote: > >> On Sat, Mar 28, 2009 at 10:53 AM, Joe Little <[email protected]> wrote: >>> >>> On Fri, Mar 27, 2009 at 9:56 PM, Daniel Beatty <[email protected]> >>> wrote: >>>> >>>> Greetings Chuck, >>>> It seems that you are quite correct as I have started to investigate >>>> this >>>> issue of SSO-WO. There is a page from Shibboleth that confirms that >>>> REMOTE_USER is the header - environment variable needed >>>> (https://spaces.internet2.edu/display/SHIB2/NativeSPEnableApplication). >>>> >>>> What value it gives and how we can use that information is a whole >>>> different >>>> story altogether. Would you be willing to advise me on creating enough >>>> of a >>>> Shibboleth - WO framework such that we could make good use of it? The >>>> work you did with Cosign and WebAuth may be highly valuable in working >>>> up >>>> some "Federated WO Authentication Framework". >>> >>> I should jump in here as we were testing Shibboleth here and were one >>> of those WebAuth sites. I'm actually switching to using just plain >>> kerberos for our next project, as at least with WebAuth and >>> furthermore with any use of the REMOTE_USER you either have to >>> (WebAuth requires https:// only sites) or should for security reasons >>> restrict everything to SSL. In my case, I have other portions of the >>> app that are best suited one-time passwords and the like for users who >>> have no relationship with us for certain actions they need. But, I >>> digress. >>> >>> The general bit is that you restrict your site via Apache to be bound >>> by mod_webauth, mod_shibboleth, etc. Thus, all users are pre-authed >>> before they get to you. You then simple check the WOContext to get the >>> value you want from the header. >>> >>> Here's the webauth example (webauth sets two vars, I went for the more >>> specific of the two: >>> >>> /** >>> * Get WebAuth User >>> **/ >>> public String webAuthUser() >>> { >>> webAuthUser = context().request().headerForKey("webauth_user"); >>> return webAuthUser; >>> } >>> >>> You'd simply switch that to "remote_user" >>> >>>> >> >> And for completeness, in your login() or similar code, we simply >> tested for a webauth session (this example is incomplete for all the >> tests you'd want to do) and if so, we avoided the login user/password >> prompt which was only effective when it wasn't an SSL session for >> development/testing >> >> /** >> * Test if there is a WebAuth User >> **/ >> public boolean isWebAuthSession() >> { >> boolean result = false; >> >> >> if (webAuthUser() != null) { >> result = true; >> ((Session)session()).setUserLogin(webAuthUser()); >> } >> return(result); >> } >> >> >> But, you get the idea. >> >> >> >>>> Thank you, >>>> Dan >>>> >>>> >>>> >>>> On Mar 11, 2009, at 10:58 PM, Chuck Hill wrote: >>>> >>>>> >>>>> On Mar 11, 2009, at 8:26 PM, TW wrote: >>>>> >>>>>> On Mar 11, 2009, at 7:37 PM, Chuck Hill wrote: >>>>>> >>>>>>> >>>>>>> On Mar 11, 2009, at 6:31 PM, TW wrote: >>>>>>> >>>>>>>> All: >>>>>>>> >>>>>>>> Our campus is going to be moving to shibboleth as the preferred sso >>>>>>>> authentication system for web apps. Has anyone here had any >>>>>>>> experience with >>>>>>>> deploying web objects apps behind this authentication mechanism? My >>>>>>>> understanding is that shibboleth really operates more at the >>>>>>>> apache/web >>>>>>>> server layer. Because of that I'm wondering what if anything really >>>>>>>> needs to >>>>>>>> be done at the app layer. >>>>>>>> >>>>>>>> Any insights, opinions, experiences, etc., would be gladly accepted >>>>>>>> and >>>>>>>> appreciated. >>>>>>>> >>>>>>>> Tim >>>>>>>> Programmer/Analyst III, UCLA GSE&IS >>>>>>> >>>>>>> Do you need to know who the user is, or just that they are >>>>>>> authenticated? >>>>>>> >>>>>>> Chuck >>>>>> >>>>>> My apps will definitely need to know who the user is. Apparently, with >>>>>> shibboleth you can designate somehow that certain data gets sent back >>>>>> to the >>>>>> requesting server - I think in the http headers. So, I'm assuming that >>>>>> there's some intention to return something that will identify the user >>>>>> since >>>>>> other systems on campus are already using it. And I think I've read >>>>>> that >>>>>> campus wants to standardize what the returned items are. >>>>> >>>>> I'd think that a very good idea. >>>>> >>>>> >>>>>> If it works as described, is sounds like it has the potential to make >>>>>> authentication to my apps easier if we choose to use this instead of >>>>>> our >>>>>> LDAP auth. Have you looked at or used shibboleth Chuck? >>>>> >>>>> >>>>> I have looked at it very briefly. I have worked with Cosign and >>>>> WebAuth >>>>> which are somewhat similar. Both of those return the sign-on ID in the >>>>> REMOTE_USER header. Shibboleth, IIRC does not, or does not guarantee >>>>> it >>>>> (something about authenticated yet anonymous users?). It can make your >>>>> apps >>>>> easier write / manage. If you get a request (or an HTTPS protected >>>>> request >>>>> depending on configuration), then you can safely assume the request is >>>>> from >>>>> an authenticated user. From there it is a simple matter to examine the >>>>> data >>>>> (usually a HTTP header) to determine user identify. >>>>> >>>>> >>>>> Chuck >>>>> >>>>> >>>>> -- >>>>> Chuck Hill Senior Consultant / VP Development >>>>> >>>>> Practical WebObjects - for developers who want to increase their >>>>> overall >>>>> knowledge of WebObjects or who are trying to solve specific problems. >>>>> http://www.global-village.net/products/practical_webobjects >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Do not post admin requests to the list. They will be ignored. >>>>> Webobjects-dev mailing list ([email protected]) >>>>> Help/Unsubscribe/Update your Subscription: >>>>> >>>>> >>>>> http://lists.apple.com/mailman/options/webobjects-dev/danielbeatty%40mac.com >>>>> >>>>> This email sent to [email protected] >>>> >>>> >>>> >>>> Dan Beatty, M.S. CS (B.S. EECS) >>>> Ph.D. Student >>>> Texas Tech University >>>> [email protected] >>>> http://venus.cs.ttu.edu/~dabeatty >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Webobjects-dev mailing list ([email protected]) >>>> Help/Unsubscribe/Update your Subscription: >>>> >>>> http://lists.apple.com/mailman/options/webobjects-dev/jmlittle%40gmail.com >>>> >>>> This email sent to [email protected] >>>> >>> > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
