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]
