These are some of the problems with WRAP authentication, and explanations of how Shibboleth handles the issues better.
Changing IP Addresses
WRAP: WRAP includes the IP address in the session cookie as a way to try to prevent other people from using another's cookie. An IP address does not uniquely identify an individual. They are often shared, and can be re-used later by another person. The user can choose to get an IP- independant cookie at login time.
Shibboleth: Shibboleth also encodes IP addresses in its sessions. However, since these cookies are tied to the host that issued them, they have fewer problems with IP address switching between connections to different servers.
The SP software has the option to decide if it will accept assertions from the IdP with the client IP does not match the encoded IP. It can also decide if it will accept SP session cookie from changed IP addresses. See the checkAddress and consistentAddress SP Session Attributes which can be changed in the shibboleth2.xml configuration file. If you use our example configuration file, we have checkAddress turned off for IdP assertions, but consistentAddress turned on for SP sessions.
WRAP: Weaknesses in Web 2.0 scripting can make it easy to capture the WRAP cookie from another user. Your browser gives out your WRAP cookie to every ncsu.edu website.
Shibboleth: Shibboleth session cookies are tied to the server where they are issued. They will not be shared to other sites. There is still a risk that a given site could suffer a cross-site scripting attack. In that case, the session cookie for that server could be stolen, but that would not allow the attack to access any other sites.
WRAP: WRAP has no way to invalidate a cookie after it has been issued, prior to the expiration time.
Shibboleth: Shibboleth uses proper session cookies: the cookie refers to a login session maintained on the server(s). When a user logs out of Shibboleth, those sessions can be terminated. If an attacker steals a session cookie, and that session has been terminated, they will not have access.
WRAP: WRAP is a homegrown, non-standard web authentication mechanism. It is not compatible with systems anywhere else.
Shibboleth: Shibboleth is a standard implementation of SAML messaging protocols. It is widely used by other institutions around the world. It can interoperate with other, non-Shibboleth SAML installations.
WRAP: WRAP relies on a single public/private key pair. It has no mechanism for distributing changes to that key.
Shibboleth: Every entity (Service Provider or Identity Provider) manages its own key pair. Federations are used to distribute these keys and to maintain a web of trust among the entities. When a key needs to be updated, it is simply a matter of registering the new key with the Federation, and the entities will collect the update from there.