Re: [cas-user] JIRA CAS configuration - is it possible to fallback to authentication against internal directory?
Hi I also encountered a problem that is very similar to yours. Can you post your web.xml configuration? Thank you 在 2018年3月17日星期六 UTC+8上午1:52:13,John Tabet写道: > > Perfect, thanks for the reply. That definitely sounds like a workable > solution. > > I also think I found another solution. Disabling all meaningful > authentication redirection in the web.xml (having all of the > tags point to something meaningless within the tags for > the cas authentication filter) while leaving the seraph-config.xml values > intact results in almost the perfectly desired behavior. JIRA now handles > all authentication detection, and so allows anonymous content to be > interacted with if the content is viewable by anonymous users. Furthermore, > all login links still point to the CAS site, and any content that returns > an authentication error also redirects to CAS. And, lastly, interacting > with any login pages (the login dialog on the landing page or directly > visiting /login.jsp) will successfully be processed by JIRA's > user login code instead of being intercepted by the CAS authentication > filter (thereby allowing users to authenticate against JIRA's internal > directory). > > On Tuesday, March 13, 2018 at 11:50:43 AM UTC-6, rbon wrote: >> >> John, >> >> Moodle has this as an option. If multiple login systems are available, >> Moodle will redirect to a page where the user can select one. You could add >> some smarts to Jira's login page to get similar behaviour. >> >> Ray >> >> On Tue, 2018-03-13 at 10:32 -0700, John Tabet wrote: >> >> Hello all, >> >> I've searched in these forums a bit, but couldn't find an answer and was >> hoping if someone could tell me if something might be possible. I've >> configured JIRA CAS authentication more or less using the instructions >> here: https://github.com/apereo/java-cas-client#atlassian-integration >> >> However, I was wondering if it's possible to configure JIRA to be able to >> fallback to internal directory authentication/ignore CAS authentication in >> some instances. I had considered configuring the URL patterns on filters to >> ignore certain URLs, but pretty sure that isn't a viable solution because >> that would mean SSO wouldn't apply to any of those URLs (which they should >> most of the time). I'm just looking for a solution that would allow me to >> authenticate to JIRA using either CAS or the internal directory, with some >> way to toggle between both authentication systems. >> >> Many thanks, >> John >> >> -- >> Ray Bon >> Programmer analyst >> Development Services, University Systems >> 2507218831 | CLE 019 | rb...@uvic.ca >> >> -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+unsubscr...@apereo.org. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/d0cae79c-9ba5-4c75-b321-cadbf59fa0d5%40apereo.org.
Re: [cas-user] JIRA CAS configuration - is it possible to fallback to authentication against internal directory?
Perfect, thanks for the reply. That definitely sounds like a workable solution. I also think I found another solution. Disabling all meaningful authentication redirection in the web.xml (having all of the tags point to something meaningless within the tags for the cas authentication filter) while leaving the seraph-config.xml values intact results in almost the perfectly desired behavior. JIRA now handles all authentication detection, and so allows anonymous content to be interacted with if the content is viewable by anonymous users. Furthermore, all login links still point to the CAS site, and any content that returns an authentication error also redirects to CAS. And, lastly, interacting with any login pages (the login dialog on the landing page or directly visiting /login.jsp) will successfully be processed by JIRA's user login code instead of being intercepted by the CAS authentication filter (thereby allowing users to authenticate against JIRA's internal directory). On Tuesday, March 13, 2018 at 11:50:43 AM UTC-6, rbon wrote: > > John, > > Moodle has this as an option. If multiple login systems are available, > Moodle will redirect to a page where the user can select one. You could add > some smarts to Jira's login page to get similar behaviour. > > Ray > > On Tue, 2018-03-13 at 10:32 -0700, John Tabet wrote: > > Hello all, > > I've searched in these forums a bit, but couldn't find an answer and was > hoping if someone could tell me if something might be possible. I've > configured JIRA CAS authentication more or less using the instructions > here: https://github.com/apereo/java-cas-client#atlassian-integration > > However, I was wondering if it's possible to configure JIRA to be able to > fallback to internal directory authentication/ignore CAS authentication in > some instances. I had considered configuring the URL patterns on filters to > ignore certain URLs, but pretty sure that isn't a viable solution because > that would mean SSO wouldn't apply to any of those URLs (which they should > most of the time). I'm just looking for a solution that would allow me to > authenticate to JIRA using either CAS or the internal directory, with some > way to toggle between both authentication systems. > > Many thanks, > John > > -- > Ray Bon > Programmer analyst > Development Services, University Systems > 2507218831 | CLE 019 | rb...@uvic.ca > > -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+unsubscr...@apereo.org. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/2f8ace5b-55a4-4ab6-9e38-9c807277cf12%40apereo.org.
Re: [cas-user] JIRA CAS configuration - is it possible to fallback to authentication against internal directory?
John, Moodle has this as an option. If multiple login systems are available, Moodle will redirect to a page where the user can select one. You could add some smarts to Jira's login page to get similar behaviour. Ray On Tue, 2018-03-13 at 10:32 -0700, John Tabet wrote: Hello all, I've searched in these forums a bit, but couldn't find an answer and was hoping if someone could tell me if something might be possible. I've configured JIRA CAS authentication more or less using the instructions here: https://github.com/apereo/java-cas-client#atlassian-integration However, I was wondering if it's possible to configure JIRA to be able to fallback to internal directory authentication/ignore CAS authentication in some instances. I had considered configuring the URL patterns on filters to ignore certain URLs, but pretty sure that isn't a viable solution because that would mean SSO wouldn't apply to any of those URLs (which they should most of the time). I'm just looking for a solution that would allow me to authenticate to JIRA using either CAS or the internal directory, with some way to toggle between both authentication systems. Many thanks, John -- Ray Bon Programmer analyst Development Services, University Systems 2507218831 | CLE 019 | r...@uvic.ca -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+unsubscr...@apereo.org. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/1520963435.1793.51.camel%40uvic.ca.