Hi Matt,
You need to know the session information from the service provider,
rather than any of the attributes. This information is kept in the log
files of both the SP and IdP, and can be used by the IdP to find the
local identity of the user, whatever attributes were released (as the
IdP doesn't have to release any at all including TargetedID if it
doesn't want to). See
https://gabriel.lse.ac.uk/twiki/bin/view/Projects/TrackUsers (though I
have yet to update this to give information for Shib 2.0 as well as 1.3).
Cheers,
Simon
Matt Dunkin wrote:
> I know this attribute has been discussed before but I can't find any reference to my question anywhere.
>
> Is there a way to get a user ID from a TargetedID using some sort of script?
>
> The differences of opinion vary all over the internet. The UK Federation website recommends the Salt value which I have to agree is the most straight forward to implement.
>
> One site says it's more secure because it's different for each Service Provider so they can't ring each other up and compare personal information based on a targetedID value. I imagine the conversation to be "ey up John, do you know anything about [log in to unmask] because I know there first name is Mike". The reply being "Ahh, so the first name is John, well I know he's an English Lecturer. Have you got the surname?". Not real, IMHO but secure all the same.
>
> The Shibboleth site states that the use of the Salt value isn't recommended for production use and that a stored value should be used. Easier for tracing, less security, contradicts the two sites above but answers my question easily. I know at least one site in the UK is doing this.
>
> The issue here is when a Service Provider rings up and wants to know who sjbsdlcbdkncdksnclsdkncdl= really is because they've been abusing a site. The only way I know is to keep shib-error.log logging everything in DEBUG mode.
>
> Has anybody tuned down LOG4J to a point where is still shows the values of the attributes so that they can be traced whilst losing all the memory clean up messages?
>
> I assume the issue of tracing back was well considered when the TargetedID attribute was chosen?
>
> Thanks,
> Matt
>
>
>
> ------------------------------------------------------------------
> Technology Specialist
> MCNE, CLE, CLP, LPIC-1
> Salford Software Ltd,
> Lancastrian Office Centre
> Talbot Road, Old Trafford
> Manchester, M32 0FP
> Tel: +44 (0) 161 906 1002 Fax: +44 (0) 161 906 1003
> Email: [log in to unmask]
> www.salfordsoftware.co.uk
> ------------------------------------------------------------------
> This email is confidential and may contain privileged material. If you
>
> are not the intended recipient then you must not copy it, forward it,
> use it for any purpose, or disclose it to another person. Instead
> please return it to the sender immediately. Please then delete your
> copy from your system.
>
> Please also note that the author of this email cannot conclude any
> contract on behalf of Salford Software Ltd by email.
> _______________________________________________
> Salford Software Free Technical Updates
> Register now!
> http://www.salfordsoftware.co.uk/education/event_details.html?event=86
>
> UCISA Identity Driven Portals Event
> Book now!
> http://www.ucisa.ac.uk/events/2007/forum/idportals/index_html
>
Please access the attached hyperlink for an important electronic communications disclaimer: http://www.lse.ac.uk/collections/secretariat/legal/disclaimer.htm
|