Re: used shibboleth
Re: used shibboleth
- Subject: Re: used shibboleth
- From: Joe Little <email@hidden>
- Date: Sun, 29 Mar 2009 14:04:26 -0700
On Sat, Mar 28, 2009 at 8:10 PM, Daniel Beatty <email@hidden> 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@hidden> wrote:
>>>
>>> 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"
>>>
>>>>
>>
>> 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@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