200 likes | 318 Views
Infrastructure for Multi-Professional Education and Training Using Shibboleth. Shibboleth Demo Overview. The setting: A user of 'University A‘ (IDP) wants to access a Shibboleth protected resource ‘Test Resource 1' hosted on ‘www.shibboleth.dmu.ac.uk’ (SP). WAYF – Where Are You From ?
E N D
Infrastructure for Multi-Professional Education and Training Using Shibboleth
Shibboleth Demo Overview The setting: A user of 'University A‘ (IDP) wants to access a Shibboleth protected resource ‘Test Resource 1' hosted on ‘www.shibboleth.dmu.ac.uk’ (SP) WAYF – Where Are You From ? IDP – Identity Provider SP – Service Provider
Shibboleth Demo Summary • Phase 1: User connects to Resource and is Redirected • Phase 2: IDP Selection • Phase 3: User Authentication at Corresponding Home Organization • Phase 4: Access 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 Grantedcont’d Click Here for Notes
Phase 4 - Access to Resource Grantedcont’d Click Here for Notes
Phase 4 - Access to Resource Grantedcont’d Click Here for Notes
Phase 4 - Access to Resource Grantedcont’d Click Here for Notes
Phase 1 - User connects to Resource and is Redirected 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 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 Grantedcont’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