<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">It appears that our authn intercept sub-flow is being called even when the subject already has an SSO session, but is requesting a subsequent SP. This is raising an issue with our intercept which relies on elements within the authentication
context which appear are going to be missing in this scenario, the LDAP response, for one.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’m sure there are valid reasons why intercepts would need to be called when building an authentication response for an existing SSO session subject, but is there a clean way of bypassing this behavior, maybe a way with the intercept sub-flow,
like a decision-state that we could use to just pass it through? I am wondering if there is something in the context tree that would tell us ‘this user already has an SSO session and we’re just building a response for the requestor’.<br>
<br>
Thanks again for any time you can give.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">Josh O’Dowd<o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:8.0pt;font-family:"Arial","sans-serif"">Software Systems Analyst / Developer<o:p></o:p></span></b></p>
<p class="MsoNormal"><i><span style="font-size:9.0pt;font-family:"Arial","sans-serif"">University of Montana, IT Central<o:p></o:p></span></i></p>
<p class="MsoNormal"><b><span style="font-size:8.0pt;font-family:"Arial","sans-serif"">(406)243-6283<o:p></o:p></span></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>