Re: used shibboleth
Re: used shibboleth
- Subject: Re: used shibboleth
- From: TW <email@hidden>
- Date: Sat, 28 Mar 2009 21:45:54 -0700
Daniel:
I'm looking into the same thing for my apps. From what I've read it
seems like there can be some level of customization between each
particular service provider and the IdP. I think the service provider
admin and the IdP admin can decide together what is going to come back
for a particular app. I get the feeling that what comes back in the
REMOTE_USER header can have multiple attributes.
Depending on the app, what comes back could be mappable to a "user"
type object or not. Along those lines, a framework might include logic
for reading preferences for:
1. Entity.name(s) you want to grab automatically
2. attribute(s) of those entities that map to the received data
You may also want some data item that helps with authorization.
There's not much needed to make a really abstract framework and each
installation is likely to be really customizable. But, I'm happy to
share whatever I come up with when I get there.
Tim
UCLA GSE&IS
On Mar 28, 2009, at 8:34 PM, Daniel Beatty wrote:
Begin forwarded message:
From: Daniel Beatty <email@hidden>
Date: March 28, 2009 10:10:29 PM CDT
To: Joe Little <email@hidden>
Cc: Daniel Beatty <email@hidden>
Subject: Re: used shibboleth
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.
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
_______________________________________________
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