|
Size: 6509
Comment:
|
Size: 9371
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 41: | Line 41: |
| || || John Watt || || | || || John Watt || Finding a compatible platform that didn't need everything built from source - which I could never get to work. Fedora Core 4 did the trick though, I would heartily recommend a flexible attitude to OS, considering there are quite a few dependent packages that need to be installed. The input that an established federation can provide, in our case the SDSS federation, proved to be invaluable in getting Shibbed in a short period of time (days rather than weeks - the federation normally responded to queries within 24 hours) plus the IdPs and SPs can be configured and tested separately before joining them together. || || || || || |
| Line 47: | Line 48: |
| || || John Watt || || | || || John Watt || It is very easy to tailor attribute release/acceptance once Shibb is running. Adding other projects to our infrastructure was not difficult. We interfaced Shibb with GridSphere successfully, and bypassed the GridSphere login to use the mod_auth_ldap authentication. The SSO capabilities of Shibb are desirable in our Grid context. || || || || || |
| Line 50: | Line 52: |
| || || Micha Bayer || as in my previous point -- can't think of anything else just now || | || || Micha Bayer || as in my previous point - can't think of anything else just now || |
| Line 53: | Line 55: |
| || || John Watt || || | || || John Watt || see scalability below || || || || || |
| Line 56: | Line 59: |
| || || Micha Bayer || || | || || Micha Bayer || A system where you have no real estimate of your '''potential''' user numbers is hard to build. This is really what it boils down to when you open things to big institutions like other universities. You would ideally want to strike a balance and devise a system which handles roughly the load you expect, but with larger numbers of potential users the load becomes harder to estimate. I guess building extensibility into the system from the start would be the answer here. || |
| Line 59: | Line 62: |
| || || John Watt || || ||'''5. how could the access control you've implemented be subverted by e.g. a bad person, or by an expert trying to get round the system for their own convenience, or by a careless user?''' || || || |
|| || John Watt || We are adopting the PERMIS role-based Access control system for authorization, which by adopting a privilege management infrastructure we hope to avoid scalability problems associated with Access Control Lists. DyVOSE is investigating dynamic delegation, which eventually will allow separate institutions to form a VO without rewriting their local security policies (we demonstrate a simplified version of this between Glasgow and Edinburgh). NeSC Glasgow is now starting to look at performance aspects of portal technology which will feed into any investigation of high-load Shibb use now our user base is increasing. || || || || || ||'''5. how could the access control you've implemented be subverted by e.g. a bad person, or by an expert trying to get round the system for their own convenience, or by a careless user?''' || || || |
| Line 62: | Line 66: |
| || || Micha Bayer || || | || || Micha Bayer || the others are in a better position to anser this as this again is really Shib-specific. || |
| Line 65: | Line 69: |
| || || John Watt || || | || || John Watt || Unless you tailor your firewall properly it is quite easy for someone who knows the system is there just to reference the URL:port directly to gain access to the Shibbed portal, and bypass authentication. If a user on a public computer doesn't log out of a session he has requested to be remembered by the IdP, it is possible that someone can re-use his session to gain access to other federation sites, which would be the same problem as if his password got stolen. || |
Developer Evaluation
In February 2006 we asked the developers from the BRIDGES and DyVOSE projects to answer a few brief questions. Contact details confirmed at http://www.nesc.ac.uk/nesc/team.html with biographies. We asked the developers to considering specifically the Shibbolizing of the Bridges web portal and DyVOSE work, and all the myriad of steps which had to be completed to make this work (PERMIS, whatever), and asked them to please identify for us:
- what did you find difficult?
- what makes Shibboleth a good solution for accessing a service like Bridges or the DyVOSE data?
- what issues can you see in a real-world production of this with 100s of users, maybe a commercial data provider, issues for the future etc.?
- what scalability issues can you identify?
- how could the access control you've implemented be subverted by e.g. a bad person, or by an expert trying to get round the system for their own convenience, or by a careless user?
To spark some real-world flavour we used the "naively"-formed scenario:
To the developer: Scenario: Please imagine you've by chance met a manager of a faculty resource in the corridor, and he/she knows of your experience and naively thinks you're the person who can just Shibb their target - "This afternoon, if you've time?"
Responses Received
We are extremely grateful to the following for responding so promptly to our scenario:
- Oluwafemi Ajayi
- Micha Bayer
(ROS: Grid/BLAST person and portlets, globus)
Micha: Please do bear in mind that I was only involved in this peripherally - I wrote the gridblast portlet and service which Jipu then continued to Shib-enable, so my knowledge of Shib is very limited indeed.
- Jipu Jiang
- Anthony Stell
- John Watt
The results can be seen below.
Results
Question |
Developer |
Answer |
1. what did you find difficult? |
|
|
|
Oluwafemi Ajayi |
|
|
Micha Bayer |
can't really comment as I was not involved in Shib-specific functionality |
|
Jipu Jiang |
|
|
Anthony Stell |
|
|
John Watt |
Finding a compatible platform that didn't need everything built from source - which I could never get to work. Fedora Core 4 did the trick though, I would heartily recommend a flexible attitude to OS, considering there are quite a few dependent packages that need to be installed. The input that an established federation can provide, in our case the SDSS federation, proved to be invaluable in getting Shibbed in a short period of time (days rather than weeks - the federation normally responded to queries within 24 hours) plus the IdPs and SPs can be configured and tested separately before joining them together. |
|
|
|
2. what makes Shibboleth a good solution for accessing a service like Bridges or the DyVOSE data? |
|
|
|
Oluwafemi Ajayi |
|
|
Micha Bayer |
It looks quite promising to me, especially for a academia-type environment where we would want to, say, give access to an application for anyone in Scotland as part of a Scottish grid. We would then not have to worry about managing our own user base but instead have arrangements with all other Scottish unis etc. This obviously relies on us being able to trace user activity and user origin/details, for example because NGS as a an end resource dictates this to us under the existing agreement. So as long as we can extract a user's DN programmatically from whithin the portal (can we?) it would be a good solution for us. That way offending users could be tracked and hopefully dealt with at their home institution. |
|
Jipu Jiang |
|
|
Anthony Stell |
|
|
John Watt |
It is very easy to tailor attribute release/acceptance once Shibb is running. Adding other projects to our infrastructure was not difficult. We interfaced Shibb with GridSphere successfully, and bypassed the GridSphere login to use the mod_auth_ldap authentication. The SSO capabilities of Shibb are desirable in our Grid context. |
|
|
|
3. what issues can you see in a real-world production of this with 100s of users, maybe a commercial data provider, issues for the future etc.? |
|
|
|
Oluwafemi Ajayi |
|
|
Micha Bayer |
as in my previous point - can't think of anything else just now |
|
Jipu Jiang |
|
|
Anthony Stell |
|
|
John Watt |
see scalability below |
|
|
|
4. what scalability issues can you identify? |
|
|
|
Oluwafemi Ajayi |
|
|
Micha Bayer |
A system where you have no real estimate of your potential user numbers is hard to build. This is really what it boils down to when you open things to big institutions like other universities. You would ideally want to strike a balance and devise a system which handles roughly the load you expect, but with larger numbers of potential users the load becomes harder to estimate. I guess building extensibility into the system from the start would be the answer here. |
|
Jipu Jiang |
|
|
Anthony Stell |
|
|
John Watt |
We are adopting the PERMIS role-based Access control system for authorization, which by adopting a privilege management infrastructure we hope to avoid scalability problems associated with Access Control Lists. DyVOSE is investigating dynamic delegation, which eventually will allow separate institutions to form a VO without rewriting their local security policies (we demonstrate a simplified version of this between Glasgow and Edinburgh). NeSC Glasgow is now starting to look at performance aspects of portal technology which will feed into any investigation of high-load Shibb use now our user base is increasing. |
|
|
|
5. how could the access control you've implemented be subverted by e.g. a bad person, or by an expert trying to get round the system for their own convenience, or by a careless user? |
|
|
|
Oluwafemi Ajayi |
|
|
Micha Bayer |
the others are in a better position to anser this as this again is really Shib-specific. |
|
Jipu Jiang |
|
|
Anthony Stell |
|
|
John Watt |
Unless you tailor your firewall properly it is quite easy for someone who knows the system is there just to reference the URL:port directly to gain access to the Shibbed portal, and bypass authentication. If a user on a public computer doesn't log out of a session he has requested to be remembered by the IdP, it is possible that someone can re-use his session to gain access to other federation sites, which would be the same problem as if his password got stolen. |
Mon 1 May |
Final doc.s to JISC |
|