Infrastructure for Multi-Professional Education and Training Using Shibboleth

The setting: A user of 'University A‘ (IDP) wants to access a Shibboleth protected resource ‘Test Resource 1' hosted on ‘ (SP) Shibboleth Demo Overview WAYF – Where Are You From ? IDP – Identity Provider SP – Service Provider

Shibboleth Demo Summary Phase 1: User connects to Resource and is RedirectedUser connects to Resource and is Redirected Phase 2: IDP SelectionIDP Selection Phase 3: User Authentication at Corresponding Home OrganizationUser Authentication at Corresponding Home Organization Phase 4:Access to Resource GrantedAccess to Resource Granted

Phase 1 - User connects to Resource and is Redirected cont’d Click Here for Notes

Phase 2 - IDP Selection cont’d Click Here for Notes

Phase 2 - IDP Selection cont’d Click Here for Notes

Phase 3 - User Authentication at Corresponding Home Organization cont’d Click Here for Notes

Phase 3 - User Authentication at Corresponding Home Organization cont’d Click Here for Notes

Phase 4 - Access to Resource Granted cont’d Click Here for Notes

Phase 4 - Access to Resource Granted cont’d Click Here for Notes

Phase 4 - Access to Resource Granted cont’d Click Here for Notes

Phase 4 - Access to Resource Granted cont’d Click Here for Notes

Transaction Summary

Notes

When the user tries to access the resource one of the following two things could happened. A. The user is granted access to the resource directly: Since the user already had a valid Shibboleth session, the user was granted access directly. This can be the case if the user previously authenticated. B. The user is redirected to the WAYF server: When the user tried to access the resource, the web server on that host detected that the user had not set up a Shibboleth session. Therefore, the user was redirected to the WAYF server. Phase 1 - User connects to Resource and is Redirected

Phase 1 - User connects to Resource and is Redirected cont’d Step 1: When the user tried to access the 'resource', The users web browser sent a HTTP request to 'shibboleth.dmu.ac.uk' for the webpage '/test_resource/resource1.jsp‘ Step 2: The web server answered with a HTTP Redirect to the WAYF server located at 'shibboleth.dmu.ac.uk/shibboleth- wayf/WAYF' because the user was not yet Shibboleth authenticated See Diagram

Phase 2 - IDP Selection Step 3: The WAYF server sent to the users web browser a HTML webpage with the pop-up list with all IDP's available. See Diagram See Screenshot

Phase 3 - User Authentication at Corresponding Home Organization Step 4: The user web browser sent the form data to the WAYF server 'shibboleth.dmu.ac.uk/shibboleth-wayf/WAYF' for the webpage '/test_resource/resource1.jsp'. The data sent, is basically the selection you made for the IDP. Step 5: The WAYF server sent your web browser a HTTP Redirect that made your web browser send a HTTP Request for the tomcat form login page of your IDP. Step 6: The web server Desktop IDP ('idp.shibboleth.dmu.ac.uk') if selected as your IDP answers with its tomcat form login webpage. See DiagramSee Screenshot

Phase 4 - Access to Resource Granted Step 7: When you clicked on 'Log in', your web browser submitted your user ID and password (your 'Credentials') to the web server of your IDP ('idp.shibboleth.dmu.ac.uk') Step 8: The web server checks the validity of user ID and password provided. An HTTP Redirect is sent to your web browser that forwards you to the resource you initially requested. Together with this redirect your web browser receives a handle (some opaque data). The web browser forwards this handle to the web server of the resource. See Diagram

Phase 4 - Access to Resource Granted cont’d Step 9: When the web server of the resource receives a handle from a user, it directly sends an attribute request to the IDP of the user by sending the handle it just received. Step 10: At the Home Organization, the handle received from the resource gets checked. To be valid, it must be presented by the resource it was issued for in step 8 and in time, i.e. before its timeout is reached. If valid, the requested user attributes for the user referred to by the handle are transmitted to the resource and checked against the attribute restraints placed on the resource. If the attributes match the restraint the target resource is shown otherwise a error page is shown stating the user is not authorised. See Diagram