george.kroner at umuc.edu
Thu Nov 6 09:57:19 EST 2014
Thank you, Nate. I guess what we are trying to replicate - maybe a variant
- is what CAS calls the "gateway" feature. This allows, for example, the
same portal page to figure out if a user is logged in or not without
"interrupting" them with a login prompt if not. This would allow a public
portal page to display certain content if the user is logged in and
generic/public content if not.
But, again, we don't have our requirements down yet - just trying to think
through options and do some brainstorming at this point. Much appreciate
On Wed, Nov 5, 2014 at 4:26 PM, Nate Klingenstein <ndk at internet2.edu> wrote:
> > Is it possible to have a SP behave such that if a user accesses a URL
> while authenticated it displays or redirects in one way and if not
> authenticated neither redirects to the login prompt nor error page but
> rather displays something different or redirects to a different URL?
> I don’t know of an intuitive way to do this in the SP itself, but there
> are thousands of examples of integrations that do what you’d like to
> achieve by a little conditional logic in the page rendering.
> > For example, accessing a URL like /webapp/whoami might return...
> > -> If authenticated, your username
> > -> If not authenticated the text "not logged in”
> You could try /Shibboleth.sso/Status as a simpler variant of this.
> > To extend this concept, accessing a URL like /webapp/classes might
> > -> If authenticated, a list of _my_ classes
> > -> If not authenticated, a list of all classes in the public catalog
> (perhaps by redirecting to /webapp/classes/public but by neither
> redirecting to a login prompt nor showing an error page)
> That’s getting very application specific and it would be very unusual to
> have something like class list display determined by the SP.
> > We are thinking of extending this to a set of REST endpoints that would
> allow authenticated users to see one thing but unauthenticated users to
> experience a different behavior. (Some users will never have SSO accounts,
> hence why we won't want to prompt everyone to login automatically.) While
> I'd never implement it this way I'm hoping to avoid something resembling a
> "send Ajax request, if HTTP 401/403 is returned do something else" pattern
> I wouldn’t do this in client code, though you could. I’d just have a
> simple switch in the web page rendering code along with whatever
> persistence/caching layer like Varnish that you may need. Here are some
> Just one perspective,
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users