I dont know how to start. My implementation for shibboleth 1.3 is for academic purpose so far and its my first experiment with Shibboleth. I dont intend to join any federation at this point. Im trying to implement shib idp 1.3 and shib sp 2.
Im using LDAP for user authentication.
After finishing all the configuration, Im not sure how to test my shibboleth idp. Most of the examples on the Internet are planning to join a federation and thus using something like this in idp.xml
and tried to write in my browser https://testidp1.org/idp1/login.jsp but didnt work.
I also would like to mention that shibboleth is not logging anything in its log files though I sure I did that in idp.xml
RE: Don't know how to test shibboleth implementation
[hidden email] wrote on 2009-06-17:
> I dont know how to start. My implementation for shibboleth 1.3 is for
> academic purpose so far and its my first experiment with Shibboleth. I
> dont intend to join any federation at this point. Im trying to implement
> shib idp 1.3 and shib sp 2.
Please consider using 2.x for all new projects, but that aside..
There are no such things as federations at the software level. If you don't
have a federation, then you have to manage trust and metadata exchange some
other way, but at the end of the process, you still end up the same
way...you generate keypairs, create the metadata, and then exchange and
reference it somehow in the two systems.
> After finishing all the configuration, Im not sure how to test my
> shibboleth idp.
You could start with testshib.org...
> In my case what I should use as a defaultRelyingParty and a providerId.
defaultRelyingParty is a meaningless setting, it's a legacy thing. Your
providerId is your choice.
Search the wiki for EntityNaming.
> Also, in my browser what should I write to test shibboleth idp:
You don't test the IdP, you set up an SP to use it and test the SP. SSO
systems don't operate in a vaccuum. There are two halves, not one. This in
turn makes it hard to "just test". But testshib was created to act as the
other half, for people engaged in activities that don't seem to have enough
real requirements to simply drive the process.