Re: [uportal-dev] Proposed CLogin Change
Sounds like a good idea. Where would the CAS login url be configured?
We have been planning to externalize that to jndi so the war / ear is
more portable between systems.
Susan
Jen Bourey wrote:
Hi all,
I'd like to propose changing the division of labor between the CLogin
channel and the theme XSL. Historically the CLogin channel has been
responsible for outputting the portal welcome message ("Welcome
yournamegoeshere"), the CAS login link or local login form, and
the logout link. When Gary first updated our XSL files for uPortal
3.0, he'd designed many of those components as XSL templates, but we
didn't actually use them, since the theme didn't know the name of the
user or CAS login URL.
In the current trunk, the theme does have access to the user's display
name, and it isn't difficult to add a Xalan helper bean that can
determine if CAS login is enabled and print the login URL. I'd like to
take advantage of those two facts to begin outputting the login and
logout URLs, as well as the welcome message from the XSL templates
directly. After that refactoring, CLogin would only be responsible for
printing out the login form for local login and any login-related
authentication errors.
I think this change would help make per-theme styling of the welcome
message and authentication links much simpler, as well as get us closer
to the original design goals of the 3.0 refactoring. Does anyone have
concerns about such a change?
- Jen
--
Jen Bourey
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: susan.bramh...@yale.edu
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
Susan Bramhall (susan.bramh...@yale.edu)
Senior Developer, Infrastructure Systems and Architecture (formerly
TP)
Yale University Information Technology Services (ITS)
25 Science Park, 150 Munson St, New Haven, CT 06520
Phone: 203 432 6697
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.comTo unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Proposed CLogin Change
The changes I've proposed don't impact the CAS configuration or anything else in security.properties. - Jen On Tue, Nov 3, 2009 at 9:27 AM, Susan Bramhall susan.bramh...@yale.eduwrote: Sounds like a good idea. Where would the CAS login url be configured? We have been planning to externalize that to jndi so the war / ear is more portable between systems. Susan Jen Bourey wrote: Hi all, I'd like to propose changing the division of labor between the CLogin channel and the theme XSL. Historically the CLogin channel has been responsible for outputting the portal welcome message (Welcome yournamegoeshere), the CAS login link or local login form, and the logout link. When Gary first updated our XSL files for uPortal 3.0, he'd designed many of those components as XSL templates, but we didn't actually use them, since the theme didn't know the name of the user or CAS login URL. In the current trunk, the theme does have access to the user's display name, and it isn't difficult to add a Xalan helper bean that can determine if CAS login is enabled and print the login URL. I'd like to take advantage of those two facts to begin outputting the login and logout URLs, as well as the welcome message from the XSL templates directly. After that refactoring, CLogin would only be responsible for printing out the login form for local login and any login-related authentication errors. I think this change would help make per-theme styling of the welcome message and authentication links much simpler, as well as get us closer to the original design goals of the 3.0 refactoring. Does anyone have concerns about such a change? - Jen -- Jen Bourey -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: susan.bramh...@yale.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- Susan Bramhall (susan.bramh...@yale.edu) Senior Developer, Infrastructure Systems and Architecture (formerly TP) Yale University Information Technology Services (ITS) 25 Science Park, 150 Munson St, New Haven, CT 06520 Phone: 203 432 6697 -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: jennifer.bou...@gmail.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- Jen Bourey -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Proposed CLogin Change
? It's the login channel that uses the security properties to get the
url. So how does universality get the url?
-Susan
Jen Bourey wrote:
The changes I've proposed don't impact the CAS
configuration or anything else in security.properties.
- Jen
On Tue, Nov 3, 2009 at 9:27 AM, Susan
Bramhall susan.bramh...@yale.edu
wrote:
Sounds like a good idea. Where would the CAS login url be configured?
We have been planning to externalize that to jndi so the war / ear is
more portable between systems.
Susan
Jen Bourey wrote:
Hi all,
I'd like to propose changing the division of labor between the CLogin
channel and the theme XSL. Historically the CLogin channel has been
responsible for outputting the portal welcome message ("Welcome
yournamegoeshere"), the CAS login link or local login form, and
the logout link. When Gary first updated our XSL files for uPortal
3.0, he'd designed many of those components as XSL templates, but we
didn't actually use them, since the theme didn't know the name of the
user or CAS login URL.
In the current trunk, the theme does have access to the user's display
name, and it isn't difficult to add a Xalan helper bean that can
determine if CAS login is enabled and print the login URL. I'd like to
take advantage of those two facts to begin outputting the login and
logout URLs, as well as the welcome message from the XSL templates
directly. After that refactoring, CLogin would only be responsible for
printing out the login form for local login and any login-related
authentication errors.
I think this change would help make per-theme styling of the welcome
message and authentication links much simpler, as well as get us closer
to the original design goals of the 3.0 refactoring. Does anyone have
concerns about such a change?
- Jen
--
Jen Bourey
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: susan.bramh...@yale.edu
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
Susan Bramhall
(susan.bramh...@yale.edu)
Senior Developer, Infrastructure Systems and Architecture (formerly
TP)
Yale University Information Technology Services (ITS)
25 Science Park, 150 Munson St, New Haven, CT 06520
Phone: 203 432 6697
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: jennifer.bou...@gmail.com
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
Jen Bourey
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: susan.bramh...@yale.edu
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
Susan Bramhall (susan.bramh...@yale.edu)
Senior Developer, Infrastructure Systems and Architecture (formerly
TP)
Yale University Information Technology Services (ITS)
25 Science Park, 150 Munson St, New Haven, CT 06520
Phone: 203 432 6697
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.comTo unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Proposed CLogin Change
The login channel actually just checks a property in security.properties - there's nothing that's really limited to the channel itself. If that value is missing, the channel assumes CAS isn't configured and that it should display the local login form. In an effort to maintain backwards compatibility, I merely copied this logic into a Xalan helper bean. I agree with you that the overall style of authentication configuration could use some updates, and it might even make sense to make that URL a more general external authentication URL, since you might plausibly use Shibboleth or some other non-CAS SSO solution. If you do decide to configure CAS via JNDI, you should be able to inject configuration into the Xalan helper bean via the Spring configuration files. - Jen On Tue, Nov 3, 2009 at 11:25 AM, Susan Bramhall susan.bramh...@yale.eduwrote: ? It's the login channel that uses the security properties to get the url. So how does universality get the url? -Susan Jen Bourey wrote: The changes I've proposed don't impact the CAS configuration or anything else in security.properties. - Jen On Tue, Nov 3, 2009 at 9:27 AM, Susan Bramhall susan.bramh...@yale.eduwrote: Sounds like a good idea. Where would the CAS login url be configured? We have been planning to externalize that to jndi so the war / ear is more portable between systems. Susan Jen Bourey wrote: Hi all, I'd like to propose changing the division of labor between the CLogin channel and the theme XSL. Historically the CLogin channel has been responsible for outputting the portal welcome message (Welcome yournamegoeshere), the CAS login link or local login form, and the logout link. When Gary first updated our XSL files for uPortal 3.0, he'd designed many of those components as XSL templates, but we didn't actually use them, since the theme didn't know the name of the user or CAS login URL. In the current trunk, the theme does have access to the user's display name, and it isn't difficult to add a Xalan helper bean that can determine if CAS login is enabled and print the login URL. I'd like to take advantage of those two facts to begin outputting the login and logout URLs, as well as the welcome message from the XSL templates directly. After that refactoring, CLogin would only be responsible for printing out the login form for local login and any login-related authentication errors. I think this change would help make per-theme styling of the welcome message and authentication links much simpler, as well as get us closer to the original design goals of the 3.0 refactoring. Does anyone have concerns about such a change? - Jen -- Jen Bourey -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: susan.bramh...@yale.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- Susan Bramhall (susan.bramh...@yale.edu) Senior Developer, Infrastructure Systems and Architecture (formerly TP) Yale University Information Technology Services (ITS) 25 Science Park, 150 Munson St, New Haven, CT 06520 Phone: 203 432 6697 -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: jennifer.bou...@gmail.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- Jen Bourey -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: susan.bramh...@yale.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- Susan Bramhall (susan.bramh...@yale.edu) Senior Developer, Infrastructure Systems and Architecture (formerly TP) Yale University Information Technology Services (ITS) 25 Science Park, 150 Munson St, New Haven, CT 06520 Phone: 203 432 6697 -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: jennifer.bou...@gmail.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- Jen Bourey -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Proposed CLogin Change
Sounds good to me. The other option instead of a Xalan helper would be to simply pass the CAS Login Enabled flag as an XSLT parameter. That would be a little more efficient since the Xalan helper stuff results in new instances of the helper for every transformation. You should be able to inject the CAS Login status as a property with a placeholder, I think security.properties is used for property replacement in the portal app context. -Eric Jen Bourey wrote: Hi all, I'd like to propose changing the division of labor between the CLogin channel and the theme XSL. Historically the CLogin channel has been responsible for outputting the portal welcome message (Welcome yournamegoeshere), the CAS login link or local login form, and the logout link. When Gary first updated our XSL files for uPortal 3.0, he'd designed many of those components as XSL templates, but we didn't actually use them, since the theme didn't know the name of the user or CAS login URL. In the current trunk, the theme does have access to the user's display name, and it isn't difficult to add a Xalan helper bean that can determine if CAS login is enabled and print the login URL. I'd like to take advantage of those two facts to begin outputting the login and logout URLs, as well as the welcome message from the XSL templates directly. After that refactoring, CLogin would only be responsible for printing out the login form for local login and any login-related authentication errors. I think this change would help make per-theme styling of the welcome message and authentication links much simpler, as well as get us closer to the original design goals of the 3.0 refactoring. Does anyone have concerns about such a change? - Jen -- Jen Bourey -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: eric.dalqu...@doit.wisc.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev smime.p7s Description: S/MIME Cryptographic Signature
