Mailing List Archive: Bricolage: devel

Bric Auth

Index | Next | Previous | View Threaded

D-Beaudet at NGA

Oct 20, 2008, 10:56 AM

Post #1 of 23 (6821 views)
Permalink

Bric Auth

There was some discussion last week on the list about modifying the way
authentication works to enable Internal via Bric DB lookup v.s. external
(i.e. Apache) authentication via other methods.

What about the built-in FTP server? That doesn't exactly benefit from
REMOTE_USER. Since it's probably a template developer-centric feature,
could we just force Internal authentication always for that feature or
does anyone have a better idea?

D-Beaudet at NGA

Oct 20, 2008, 11:03 AM

Post #2 of 23 (6694 views)
Permalink

RE: Bric Auth [In reply to]

OK, never mind about falling back. I see that AUTH_ENGINES is a space
delimited list that is designed to try each engine in order... so FTP
would be fine so long as Internal is not removed from the AUTH_ENGINES
list and the password for FTP is synced up with the Bricolage DB.

Only drawback here is that the credentials for the FTP server are not
centralized.

-----Original Message-----
From: Beaudet, David [mailto:D-Beaudet [at] NGA]
Sent: Monday, October 20, 2008 1:56 PM
To: devel [at] lists
Subject: Bric Auth

There was some discussion last week on the list about modifying the way
authentication works to enable Internal via Bric DB lookup v.s. external
(i.e. Apache) authentication via other methods.

What about the built-in FTP server? That doesn't exactly benefit from
REMOTE_USER. Since it's probably a template developer-centric feature,
could we just force Internal authentication always for that feature or
does anyone have a better idea?

rolfm at denison

Oct 20, 2008, 12:27 PM

Post #3 of 23 (6705 views)
Permalink

Re: Bric Auth [In reply to]

BTW David, I was planning to develop this against trunk.

-Matt

On Oct 20, 2008, at 2:03 PM, Beaudet, David wrote:

>
> OK, never mind about falling back. I see that AUTH_ENGINES is a space
> delimited list that is designed to try each engine in order... so FTP
> would be fine so long as Internal is not removed from the AUTH_ENGINES
> list and the password for FTP is synced up with the Bricolage DB.
>
> Only drawback here is that the credentials for the FTP server are not
> centralized.
>
> -----Original Message-----
> From: Beaudet, David [mailto:D-Beaudet [at] NGA]
> Sent: Monday, October 20, 2008 1:56 PM
> To: devel [at] lists
> Subject: Bric Auth
>
>
>
> There was some discussion last week on the list about modifying the
> way
> authentication works to enable Internal via Bric DB lookup v.s.
> external
> (i.e. Apache) authentication via other methods.
>
>
>
> What about the built-in FTP server? That doesn't exactly benefit from
> REMOTE_USER. Since it's probably a template developer-centric
> feature,
> could we just force Internal authentication always for that feature or
> does anyone have a better idea?
>
>
>
>
>

rolfm at denison

Nov 27, 2008, 9:29 AM

Post #4 of 23 (6550 views)
Permalink

Re: Bric Auth [In reply to]

Just an update to the list on this, David Beaudet has made great
progress, and we're working on helping him test it. There is a little
more work to be done to get it working with 2.0, I think. Work was
held up because I've had to juggle a number of projects on my end.
I'd like to see us make it in under the feature freeze of Dec. 19th.

My colleague Mike and I are also going to take a look at tackling Bugs
1382-1384 (improve profile deletion scheme) before that time.

-Matt

david at kineticode

Nov 27, 2008, 12:44 PM

Post #5 of 23 (6549 views)
Permalink

Re: Bric Auth [In reply to]

On Nov 27, 2008, at 6:29 PM, Matt Rolf wrote:

> Just an update to the list on this, David Beaudet has made great
> progress, and we're working on helping him test it. There is a
> little more work to be done to get it working with 2.0, I think.
> Work was held up because I've had to juggle a number of projects on
> my end. I'd like to see us make it in under the feature freeze of
> Dec. 19th.

Great, thanks!

> My colleague Mike and I are also going to take a look at tackling
> Bugs 1382-1384 (improve profile deletion scheme) before that time.

W00t!

Best,

David

rolfm at denison

Dec 16, 2008, 1:09 PM

Post #6 of 23 (6418 views)
Permalink

Re: Bric Auth [In reply to]

More to report on Bric Auth, I've taken David's code and gotten it to
work with 2.0. There is a bit more polishing to be done, but I hope
to commit the final version of the code before the end of the month,
if not sooner - I hope that it will be fine to get it into the next
version of the devel release.

-Matt

On Nov 27, 2008, at 3:44 PM, David E. Wheeler wrote:

> On Nov 27, 2008, at 6:29 PM, Matt Rolf wrote:
>
>> Just an update to the list on this, David Beaudet has made great
>> progress, and we're working on helping him test it. There is a
>> little more work to be done to get it working with 2.0, I think.
>> Work was held up because I've had to juggle a number of projects on
>> my end. I'd like to see us make it in under the feature freeze of
>> Dec. 19th.
>
> Great, thanks!
>
>> My colleague Mike and I are also going to take a look at tackling
>> Bugs 1382-1384 (improve profile deletion scheme) before that time.
>
> W00t!
>
> Best,
>
> David
>

david at kineticode

Dec 16, 2008, 1:23 PM

Post #7 of 23 (6423 views)
Permalink

Re: Bric Auth [In reply to]

On Dec 16, 2008, at 10:09 PM, Matt Rolf wrote:

> More to report on Bric Auth, I've taken David's code and gotten it
> to work with 2.0. There is a bit more polishing to be done, but I
> hope to commit the final version of the code before the end of the
> month, if not sooner - I hope that it will be fine to get it into
> the next version of the devel release.

matt++

David

rolfm at denison

Dec 16, 2008, 1:42 PM

Post #8 of 23 (6412 views)
Permalink

Re: Bric Auth [In reply to]

On Dec 16, 2008, at 4:23 PM, David E. Wheeler wrote:

> On Dec 16, 2008, at 10:09 PM, Matt Rolf wrote:
>
>> More to report on Bric Auth, I've taken David's code and gotten it
>> to work with 2.0. There is a bit more polishing to be done, but I
>> hope to commit the final version of the code before the end of the
>> month, if not sooner - I hope that it will be fine to get it into
>> the next version of the devel release.
>
> matt++

David B.+++

rolfm at denison

Feb 23, 2009, 12:43 PM

Post #9 of 23 (5955 views)
Permalink

Re: Bric Auth [In reply to]

On Dec 16, 2008, at 4:42 PM, Matt Rolf wrote:

>
> On Dec 16, 2008, at 4:23 PM, David E. Wheeler wrote:
>
>> On Dec 16, 2008, at 10:09 PM, Matt Rolf wrote:
>>
>>> More to report on Bric Auth, I've taken David's code and gotten it
>>> to work with 2.0. There is a bit more polishing to be done, but I
>>> hope to commit the final version of the code before the end of the
>>> month, if not sooner - I hope that it will be fine to get it into
>>> the next version of the devel release.
>>
>> matt++

As I mentioned prior, the code is almost ready to commit. However, I
want to pose a question to the list as to how we should handle logouts
before I commit it.

David B. coded the logout button to drop away when Apache
Authentication is in operation. At first I didn't think this made
sense, and suggested that we add a page that would kill the Bric
Session when the user clicks logout. But the more we've talked about
it here at Denison, the more David's implementation seems to make
sense. Reason being, apache doesn't care, it will still keep you
logged in even if the bric session is dead. And if someone's using a
SSO tool like CAS, then they might have their own url they might want
to direct to on login

So I'd like to get feedback from others as to the best way to handle
this. My current thought is to commit it as is (no logout button when
Apache Auth is on). Maybe we want to add a custom logout url to
bricolage.conf directory? I'm not sure.

-Matt

david at kineticode

Feb 23, 2009, 12:47 PM

Post #10 of 23 (5970 views)
Permalink

Re: Bric Auth [In reply to]

On Feb 23, 2009, at 12:43 PM, Matt Rolf wrote:

> As I mentioned prior, the code is almost ready to commit. However,
> I want to pose a question to the list as to how we should handle
> logouts before I commit it.
>
> David B. coded the logout button to drop away when Apache
> Authentication is in operation. At first I didn't think this made
> sense, and suggested that we add a page that would kill the Bric
> Session when the user clicks logout. But the more we've talked
> about it here at Denison, the more David's implementation seems to
> make sense. Reason being, apache doesn't care, it will still keep
> you logged in even if the bric session is dead. And if someone's
> using a SSO tool like CAS, then they might have their own url they
> might want to direct to on login

Is there no way to kill the Apache login?

> So I'd like to get feedback from others as to the best way to handle
> this. My current thought is to commit it as is (no logout button
> when Apache Auth is on). Maybe we want to add a custom logout url to
> bricolage.conf directory? I'm not sure.

Not sure I follow you here.

Best,

David

D-Beaudet at NGA

Feb 23, 2009, 12:58 PM

Post #11 of 23 (5959 views)
Permalink

RE: Bric Auth [In reply to]

Slight enhancement to what Matt said. The logout button only disappears
if you are currently logged in via an Apache Auth mechanism, not if you
are logged in via Bricolage's auth mechanism.

For example, if you are logged in via Apache Auth, then as a Bric admin,
login as another Bric user from the user list page, the logout button
will reappear.

When you click logout from that user, you are then re-authenticated via
Apache Auth and taken immediately to your workspace page and the logout
button disappears again.

It very well might make more sense to keep the logout button all the
time, but if we do that we first have to define the contents of the page
that will be displayed when an Apache-authed user clicks logout.

In another system we have that is SSO-enabled, there's an interim page
that says something like: "You have been logged out of the system, click
the button below to return".

The whole point being that if I'm logged in with an Apache Auth
mechanism and I click logout, it doesn't make sense to be taken back to
the Bricolage login page with a username: password: dialog; and it seems
like a usability issue to have a button added to that page that says:
"login automatically with Apache authentication instead".

Hope this helps,

Dave

> -----Original Message-----
> From: David E. Wheeler [mailto:david [at] kineticode]
> Sent: Monday, February 23, 2009 3:47 PM
> To: devel [at] lists
> Subject: Re: Bric Auth
>
> On Feb 23, 2009, at 12:43 PM, Matt Rolf wrote:
>
> > As I mentioned prior, the code is almost ready to commit. However,
> > I want to pose a question to the list as to how we should handle
> > logouts before I commit it.
> >
> > David B. coded the logout button to drop away when Apache
> > Authentication is in operation. At first I didn't think this made
> > sense, and suggested that we add a page that would kill the Bric
> > Session when the user clicks logout. But the more we've talked
> > about it here at Denison, the more David's implementation seems to
> > make sense. Reason being, apache doesn't care, it will still keep
> > you logged in even if the bric session is dead. And if someone's
> > using a SSO tool like CAS, then they might have their own url they
> > might want to direct to on login
>
> Is there no way to kill the Apache login?
>
> > So I'd like to get feedback from others as to the best way to handle
> > this. My current thought is to commit it as is (no logout button
> > when Apache Auth is on). Maybe we want to add a custom logout url to
> > bricolage.conf directory? I'm not sure.
>
> Not sure I follow you here.
>
> Best,
>
> David

D-Beaudet at NGA

Feb 23, 2009, 1:06 PM

Post #12 of 23 (5981 views)
Permalink

RE: Bric Auth [In reply to]

> Is there no way to kill the Apache login?

No straightforward way that I'm aware of -- unless a directive can be
toggled while Apache is running. But I'm not clear on the advantage of
being able to do that.

rolfm at denison

Feb 23, 2009, 1:17 PM

Post #13 of 23 (5963 views)
Permalink

Re: Bric Auth [In reply to]

On Feb 23, 2009, at 3:47 PM, David E. Wheeler wrote:

> Is there no way to kill the Apache login?

I do not believe that there is.

>> So I'd like to get feedback from others as to the best way to
>> handle this. My current thought is to commit it as is (no logout
>> button when Apache Auth is on). Maybe we want to add a custom
>> logout url to bricolage.conf directory? I'm not sure.
>
> Not sure I follow you here.

Let's say someone is using an Apache Auth tie-in that assigns remote
user based on the ticket from some other SSO app. If they want people
to be able to log out of that SSO entity, we could provide a config
directive for a custom url. Therefore, the logout would show up when
they added the custom url, but not otherwise when apache auth was
enabled.

-Matt

david at kineticode

Feb 23, 2009, 1:48 PM

Post #14 of 23 (5967 views)
Permalink

Re: Bric Auth [In reply to]

On Feb 23, 2009, at 12:58 PM, Beaudet, David wrote:

> It very well might make more sense to keep the logout button all the
> time, but if we do that we first have to define the contents of the
> page
> that will be displayed when an Apache-authed user clicks logout.
>
> In another system we have that is SSO-enabled, there's an interim page
> that says something like: "You have been logged out of the system,
> click
> the button below to return".

That makes sense. It should also say, "If you're at a public terminal,
please quit the browser.". That should properly logout the user, no?

> The whole point being that if I'm logged in with an Apache Auth
> mechanism and I click logout, it doesn't make sense to be taken back
> to
> the Bricolage login page with a username: password: dialog; and it
> seems
> like a usability issue to have a button added to that page that says:
> "login automatically with Apache authentication instead".

Right, there should be another page for that. That's fine with me. It
can be based on the welcome page.

Best,

David

david at kineticode

Feb 23, 2009, 1:49 PM

Post #15 of 23 (5970 views)
Permalink

Re: Bric Auth [In reply to]

On Feb 23, 2009, at 1:17 PM, Matt Rolf wrote:

> Let's say someone is using an Apache Auth tie-in that assigns
> remote user based on the ticket from some other SSO app. If they
> want people to be able to log out of that SSO entity, we could
> provide a config directive for a custom url. Therefore, the logout
> would show up when they added the custom url, but not otherwise when
> apache auth was enabled.

But you should be logged out if you quit the browser, no?

Best,

David

marshall at exclupen

Feb 23, 2009, 1:59 PM

Post #16 of 23 (5966 views)
Permalink

Re: Bric Auth [In reply to]

On Feb 23, 2009, at 4:49 PM, David E. Wheeler wrote:

> On Feb 23, 2009, at 1:17 PM, Matt Rolf wrote:
>
>> Let's say someone is using an Apache Auth tie-in that assigns
>> remote user based on the ticket from some other SSO app. If they
>> want people to be able to log out of that SSO entity, we could
>> provide a config directive for a custom url. Therefore, the logout
>> would show up when they added the custom url, but not otherwise
>> when apache auth was enabled.
>
> But you should be logged out if you quit the browser, no?

Not with mod_pubcookie. You are issued a cookie from the Pubcookie
server, which can persist across browser sessions.

--
Marshall

marshall at exclupen

Feb 23, 2009, 2:04 PM

Post #17 of 23 (5955 views)
Permalink

Re: Bric Auth [In reply to]

On Feb 23, 2009, at 4:48 PM, David E. Wheeler wrote:

>> The whole point being that if I'm logged in with an Apache Auth
>> mechanism and I click logout, it doesn't make sense to be taken
>> back to
>> the Bricolage login page with a username: password: dialog; and it
>> seems
>> like a usability issue to have a button added to that page that says:
>> "login automatically with Apache authentication instead".
>
> Right, there should be another page for that. That's fine with me.
> It can be based on the welcome page.

Shouldn't it just redirect you back to the SSO login page if you're
not logged in?

1. bricolage.example.com
2. redirects to cas.example.com/login
3. after user logs in, redirects to bricolage.example.com
4. user clicks "Log out", sends user to...
5. cas.example.com/logout (kills SSO session cookie, unrelated to
Bricolage)
6. redirects to bricolage.example.com
7. redirects to cas.example.com/login
8. repeat...

--
Marshall

marshall at exclupen

Feb 23, 2009, 2:06 PM

Post #18 of 23 (5966 views)
Permalink

Re: Bric Auth [In reply to]

In other words, how do you even get to the Bricolage login page to see
that username/password dialog if the Apache auth is configured to
intercept and force you to log in before you even reach Bricolage?

On Feb 23, 2009, at 5:04 PM, Marshall Roch wrote:

> On Feb 23, 2009, at 4:48 PM, David E. Wheeler wrote:
>
>>> The whole point being that if I'm logged in with an Apache Auth
>>> mechanism and I click logout, it doesn't make sense to be taken
>>> back to
>>> the Bricolage login page with a username: password: dialog; and it
>>> seems
>>> like a usability issue to have a button added to that page that
>>> says:
>>> "login automatically with Apache authentication instead".
>>
>> Right, there should be another page for that. That's fine with me.
>> It can be based on the welcome page.
>
> Shouldn't it just redirect you back to the SSO login page if you're
> not logged in?
>
> 1. bricolage.example.com
> 2. redirects to cas.example.com/login
> 3. after user logs in, redirects to bricolage.example.com
> 4. user clicks "Log out", sends user to...
> 5. cas.example.com/logout (kills SSO session cookie, unrelated to
> Bricolage)
> 6. redirects to bricolage.example.com
> 7. redirects to cas.example.com/login
> 8. repeat...
>
> --
> Marshall

D-Beaudet at NGA

Feb 23, 2009, 7:36 PM

Post #19 of 23 (5964 views)
Permalink

RE: Bric Auth [In reply to]

>In other words, how do you even get to the Bricolage login page to see
>that username/password dialog if the Apache auth is configured to
>intercept and force you to log in before you even reach Bricolage?

You don't. That's actually one of the nice things about one incarnation of SSO, sometimes called transparent SSO, in which the browser passes O/S credentials transparently to the application and logs someone in automatically.

david at kineticode

Feb 24, 2009, 8:20 AM

Post #20 of 23 (5948 views)
Permalink

Re: Bric Auth [In reply to]

On Feb 23, 2009, at 7:36 PM, Beaudet, David wrote:

>> In other words, how do you even get to the Bricolage login page to
>> see
>> that username/password dialog if the Apache auth is configured to
>> intercept and force you to log in before you even reach Bricolage?
>
> You don't. That's actually one of the nice things about one
> incarnation of SSO, sometimes called transparent SSO, in which the
> browser passes O/S credentials transparently to the application and
> logs someone in automatically.

Remind me to borrow your computer when I come to visit you in DC. ;-P

D

D-Beaudet at NGA

Feb 24, 2009, 10:28 AM

Post #21 of 23 (5948 views)
Permalink

RE: Bric Auth [In reply to]

Ha! Don't get me started.

-----Original Message-----
From: David E. Wheeler [mailto:david [at] kineticode]
Sent: Tue 2/24/2009 11:20 AM
To: devel [at] lists
Subject: Re: Bric Auth

On Feb 23, 2009, at 7:36 PM, Beaudet, David wrote:

>> In other words, how do you even get to the Bricolage login page to
>> see
>> that username/password dialog if the Apache auth is configured to
>> intercept and force you to log in before you even reach Bricolage?
>
> You don't. That's actually one of the nice things about one
> incarnation of SSO, sometimes called transparent SSO, in which the
> browser passes O/S credentials transparently to the application and
> logs someone in automatically.

Remind me to borrow your computer when I come to visit you in DC. ;-P

D

fulekia at denison

Feb 25, 2009, 6:43 AM

Post #22 of 23 (5942 views)
Permalink

Re: Bric Auth [In reply to]

On Feb 23, 2009, at 5:04 PM, Marshall Roch wrote:
<snip>
> 4. user clicks "Log out", sends user to...
> 5. cas.example.com/logout (kills SSO session cookie, unrelated to
> Bricolage)
> 6. redirects to bricolage.example.com
> 7. redirects to cas.example.com/login
> 8. repeat...
</snip>

Not all SSO systems, clients, or implementations support Single Sign
*Out* AFAIK. Or if they did, it may not be desirable in all user
scenarios.

In a complex intranet environment for example, users may log into a
web portal or application server, and move pretty much arbitrarily
between apps and whatnot. If any one of them could send a single sign
out request back up the chain, borking other app sessions, that could
be annoying to no end.

I'm all for no logout button - if implementors have a fully-baked
single sign out strategy for their user experience, more power to'em.
I say "quit the browser", and leave the decision in user land.

-Aaron

---------------------------------
Aaron Fuleki
Web Services Manager
Denison University
740.587.5752
---------------------------------

rolfm at denison

Mar 5, 2009, 5:38 PM

Post #23 of 23 (5848 views)
Permalink

Re: Bric Auth [In reply to]

On Feb 25, 2009, at 9:43 AM, Aaron Fuleki wrote:

> On Feb 23, 2009, at 5:04 PM, Marshall Roch wrote:
> <snip>
>> 4. user clicks "Log out", sends user to...
>> 5. cas.example.com/logout (kills SSO session cookie, unrelated to
>> Bricolage)
>> 6. redirects to bricolage.example.com
>> 7. redirects to cas.example.com/login
>> 8. repeat...
> </snip>
>
> Not all SSO systems, clients, or implementations support Single Sign
> *Out* AFAIK. Or if they did, it may not be desirable in all user
> scenarios.
>
> In a complex intranet environment for example, users may log into a
> web portal or application server, and move pretty much arbitrarily
> between apps and whatnot. If any one of them could send a single
> sign out request back up the chain, borking other app sessions, that
> could be annoying to no end.
>
> I'm all for no logout button - if implementors have a fully-baked
> single sign out strategy for their user experience, more power
> to'em. I say "quit the browser", and leave the decision in user land.

Did we ever reach a consensus on this? Can I commit with no logout
button or shall I hold off?

-Matt

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads