obtaining relying party acs endpoint

Chad La Joie lajoie at itumi.biz
Thu Sep 15 21:05:41 BST 2011


Ah, okay, I see what you mean now.  And yeah, I understand not wanting
to modify the core code.  That said, the change your talking about I
*think* could be kept as a patch that would almost always apply, I
think.  It's pretty rare that we change that base class
(AbstractSAMLProfileHandler if I recall correctly).

On Thu, Sep 15, 2011 at 15:49, Paul Hethmon
<paul.hethmon at clareitysecurity.com> wrote:
> It's more the Saml2LoginContext:
>
> public Saml2LoginContext(String relyingParty, String state, AuthnRequest
> request)
>
>
> Since that object is exposed via HttpServletHelper to my login handler, if
> it had the info, I could write it out in my own log file. Everyone I
> integrate with is SAML2, so that would cover my situation.
>
> I just hate modifying the base code since it's another point to break when
> I update.
>
> thanks,
>
> Paul
>
>
>
> On 9/15/11 3:33 PM, "Chad La Joie" <lajoie at itumi.biz> wrote:
>
>>I'm not quite sure how the LoginContext really figures in to what
>>you're asking, but yeah, if you want it in the audit log you'll need
>>to adjust the profile handler to add it in.
>>
>>On Thu, Sep 15, 2011 at 15:25, Paul Hethmon
>><paul.hethmon at clareitysecurity.com> wrote:
>>> I've got some relying parties with multiple applications that share the
>>>same
>>> entityID configuration wise (on my side). Which application the user
>>>goes to
>>> is controlled in part by the ACS endpoint in the AuthnRequest that
>>>comes in.
>>> In order to provide better usage reporting to my customers, I'd like to
>>> capture the requested ACS endpoint in a log file. The normal audit log
>>>file
>>> doesn't contain that level of detail.
>>> I've been poring through the code but it appears that the determination
>>>of
>>> the endpoint doesn't happen until authentication is over and execution
>>>is
>>> back in the profile handler code. The LoginContext has access to the
>>> information in the ctor, but doesn't actually extract it.
>>> So, it appears I have two ways to do it:
>>> 1. Modify the base LoginContext code to put that information into the
>>> object.
>>> 2. Modify the ProfileHandler code to add that bit of information to the
>>> standard audit log.
>>> Neither of which is desirable from a code maintenance point of view. Am
>>>I
>>> missing another option?
>>> thanks,
>>> Paul
>>>
>>> --
>>> Paul Hethmon
>>> Chief Software Architect
>>> Clareity Security, LLC
>>> o) 865.824.1350
>>> c) 865.250.3517
>>> e) paul.hethmon at clareitysecurity.com
>>>
>>> --
>>> To unsubscribe from this list send an email to
>>> dev-unsubscribe at shibboleth.net
>>>
>>
>>
>>
>>--
>>Chad La Joie
>>www.itumi.biz
>>trusted identities, delivered
>>--
>>To unsubscribe from this list send an email to
>>dev-unsubscribe at shibboleth.net
>
> --
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net
>



-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered


More information about the dev mailing list