Re: used shibboleth
Re: used shibboleth
- Subject: Re: used shibboleth
- From: Joe Little <email@hidden>
- Date: Sat, 28 Mar 2009 10:53:05 -0700
On Fri, Mar 27, 2009 at 9:56 PM, Daniel Beatty <email@hidden> 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"
>
> 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@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>>
>> This email sent to email@hidden
>
>
>
> Dan Beatty, M.S. CS (B.S. EECS)
> Ph.D. Student
> Texas Tech University
> email@hidden
> http://venus.cs.ttu.edu/~dabeatty
>
>
>
>
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden