<div>Thank you for the thoughtful replies. </div><div><br></div>It would be advantageous to get the third party attributes into Shibboleth attributes for logging, auditing, etc.<div><br></div><div>Regarding building a custom data connector, V2 is well documented regarding spring custom config schema etc. For v3, I generally read the source code. Could you point me to where I should start?</div><div><br></div><div>Thank you,</div><div><br></div>cg<span></span><br><div><div><br>On Friday, June 26, 2015, Cantor, Scott <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> > It appears that the best approach is to write a custom Data Connector that<br>
> > loads attributes from the API and makes them available to the rest of<br>
> > Shibboleth idP. Am I on the right path?<br>
><br>
> Likely. Particularly if you mean that the format of that data is fairly esoteric<br>
> and you want to just get it into the resolver in string form I guess.<br>
<br>
That said, sadly writing a flow is easier than the custom data connector part. The connector's easy, but we're still using the old config schema for the resolver, so you would generally speaking need to create all the custom Spring parser and schema stuff like with V2's plugins to get it usable in the resolver's config file.<br>
<br>
As I say that though, I think there's a way you could just define your connector's bean in Spring format and then reference it by bean ID in the resolver. I know we were trying to make that viable so that people doing local extensions could skip all the parser nonsense, but I don't know where we got to on that, should be at least mentioned in the resolver config doc pages.<br>
<br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="javascript:;" onclick="_e(event, 'cvml', 'users-unsubscribe@shibboleth.net')">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div></div>