|
Size: 34269
Comment:
|
Size: 34644
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 62: | Line 62: |
| Shibboleth looks quite promising especially for an academic environment where we would want to, say, give access to an application for anyone in Scotland as part of a Scottish grid. The developers would then not have to worry about managing their own user base but instead have arrangements with all other Scottish universities etc. This obviously relies on the developers' being able to trace user activity and user origin/details, for example because the National Grid Service (NGS) as an end resource dictates this to the developers under the existing agreement. So as long as they can extract a user's distinguished name (DN) programmatically from within the portal (xxxx Note from Micha ''can we?'') it would be a good solution for the developers. That way offending users could be tracked and hopefully dealt with at their home institution. | Shibboleth looks quite promising especially for an academic environment where we would want to, say, give access to an application for anyone in Scotland as part of a Scottish grid. The developers would then not have to worry about managing their own user base but instead have arrangements with all other Scottish universities etc. This obviously relies on the developers' being able to trace user activity and user origin/details, for example because the National Grid Service (NGS) as an end resource dictates this to the developers under the existing agreement. So as long as they can extract a user's distinguished name (DN) programmatically from within the portal it would be a good solution for the developers. That way offending users could be tracked and hopefully dealt with at their home institution. {{{ AE: Note from Micha "can we" extract a user's DN programmatically from within the portal?) (-- AlunEdwards [[DateTime(2006-04-11T16:39:40Z)]]) }}} |
| Line 87: | Line 92: |
| * "''I'm sure there are holes in PERMIS that I'm not aware of''" which means that this situation "''is worse than no security, it's the illusion of security''." | * "''I'm sure there are holes in PERMIS that I'm not aware of''" which means that this situation "''is worse than no security, it's the illusion of security''." |
| Line 92: | Line 97: |
| === Access control lists === The developers have adopted a privilege management infrastructure (the PERMIS role-based access control system for authorisation) intending to avoid scalability problems associated with Access Control Lists. |
|
| Line 93: | Line 100: |
| Micha Bayer |
=== Re-writing local security policies === DyVOSE is investigating dynamic delegation, which eventually will allow separate institutions to form a Virtual Organisation (VO) without re-writing their local security policies. DyVOSE demonstrates a simplified version of this between the universities of Glasgow and Edinburgh. |
| Line 96: | Line 103: |
| 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. | === User role === A problem with expanding [xxxx] is that user role which is specified by the Identity Provider (IdP) and required by the Service Provider (SP) may not be the same. So that, to access a specific grid service either the IdP have to change user role to fit to the SP specification or the will SP have to change its policy to fit the IdP. To solve this, the best way is to negotiate the relationship between roles, or unify different roles from different organizations. |
| Line 98: | Line 106: |
| Jipu Jiang But it does have a problem in expanding. User Role specified by the IdP and required by the SP may not be the same. So that, to access a specific grid service, IdP have to change user role to fit to the SP specification or the other way around, SP have to change its policy to fit the IdP. To solve this, the best way is to negotiate the relationship between roles, or unify different roles from different organizations. Anthony Stell Though I don't know for sure, I can almost guarantee that PERMIS hasn't been tested for scalability in anger (> about 10 users). I predict that when this happens, performance will slow down chronically on any given system. The code just seems to be quite bloated, and this will be a problem when combined with Globus services, which are themselves not incredibly efficient. # The LDAP server back-end that PERMIS uses would also have to be managed automatically. I'm not aware of any tools out there that do this just now, and I think this would have to be a manual process anyway, because in any security process, human verification of credentials is essential at some point. I reckon some kind of automated management tool such as this could be built, but I'm not sure how it would fit in to the whole infrastructure. 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. |
{{{ [xxxx] AE insert here: grid / user base / resource? (-- AlunEdwards [[DateTime(2006-04-11T16:39:40Z)]]) }}} |
| Line 120: | Line 111: |
| === PERMIS === The developer with expertise in PERMIS believes that it has not been tested for scalability in anger. When PERMIS is used with more than 10 users the developer predicts that performance will slow down chronically on any given system. This is because the code seems to be quite bloated, and this will be a problem when combined with Globus services, "''which are themselves not incredibly efficient''". |
|
| Line 121: | Line 114: |
| ==== LDAP server back-end ==== The LDAP server back-end that PERMIS uses would also have to be managed automatically. The same developer is not currently aware of any tools that do this, and predicts that this would have to be a manual process anyway (because in any security process, human verification of credentials is essential at some point). Some kind of automated management tool such as this '''could''' be built, but then how would it fit in to the whole infrastructure? === Growing user base === 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. Building extensibility into the system from the start would be the answer here. 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 the grid's user base is increasing. |
|
| Line 124: | Line 122: |
| === Firewall === | |
| Line 125: | Line 124: |
| Unless you tailor your firewall properly it is quite easy for someone who knows the system is there just to reference the URI : port directly to gain access to the Shibbed portal, and bypass authentication. Currently, the developers force the user request through the Apache Shib module first to do authentication, then the request is redirected to the Portal container. For example: * A malicious user can go directly to the portal container if they know the address and port. Our portal container is located at xxx.xxx.xxx.xxx:8080, and we force user requests go to xxx.xxx.xxx.xxx:80, and then any request to the container no longer goes through 8080, instead, goes through 80. In this case, we have to block the 8080 port on the server, and only leave port 80 open. * Another possibility is that, users manage to know the URI to the actual Grid service. This is possible - but unlikely - because the Servlet container and relative dynamic page technology are designed to prevent this from the beginning. Further, even if they know the URI of the Grid service, they would still need the JAR file of the grid service as library to invoke the service. Such weakness must be prevented by using the firewall to block certain ports. |
|
| Line 126: | Line 129: |
| ==== PERMIS ==== One of the major requirements to come out of the BRIDGES project was the need for usability. Biologists were simply not going to use the applications if they had to do complicated things like get UK e-Science certificates for themselves. Unfortunately, PERMIS requires PKI certificates to get the username (see xxxx authn-agnostic above). So the developers had to use a test program, to use PERMIS as a look-up system rather than integrating it completely with the BLAST service, and have the service call the URI from a specified string (this is the hack that I referred to in xxxx above). The developer with PERMIS expertise '''thinks''' this means that if anyone knows the PERMIS service URI specifically, it could be hacked - though the firewall is closed on the PERMIS server. '''However this is something that could be easily missed during implementation.''' |
|
| Line 127: | Line 132: |
| John Watt |
=== Public computer === If a user on a public computer does not 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. |
| Line 130: | Line 135: |
| Unless you tailor your firewall properly it is quite easy for someone who knows the system is there just to reference the U R L : port [XXXX AE: written like this to cheat the wiki formatting!] 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. Micha Bayer the others are in a better position to anser this as this again is really Shib-specific. Jipu Jiang Currently, we force the user request come through the Apache Shib module first to do authentication, then the request is redirected to the Portal container. Malicious user can go directly to the portal container if they know the address and port. Such weakness must be prevented by using firewall to block certain port. For example, our portal container located at xxx.xxx.xxx.xxx:8080, and we force user requests go to xxx.xxx.xxx.xxx:80, and then any request to the container no longer go through 8080, instead, go through 80. in this case, we have to block the 8080 port on the server, and only leave port 80 open. Another possibility is that, users manage to know the URI to the actual Grid service. It is unlikely possible because the Servlet container and relative dynamic page technology are designed to prevent this from the beginning. Further, even they know the URI of the Grid service, they would still need the JAR file of the Grid service as library to invoke the service. Anthony Stell This is similar to John's answer. One of the major requirements to come out of the BRIDGES project was the need for usability. Biologists were simply not going to use our applications if they had to do complicated things like get UK e-Science certificates for themselves. # Unfortunately, PERMIS requires PKI certificates to get the username (see, not really authn-agnostic :o). So we had to use a test program, to use PERMIS as a look-up system rather than integrating it completely with the BLAST service, and have the service call the URI from a specified string (this is the hack that I referred to). I think this means that if anyone knows the PERMIS service URI specifically, it could be hacked - though I've closed the firewall on the PERMIS server, so it should be ok now. But it's something that could be easily missed during implementation. # As you can probably tell, I've got a fair amount of bad things to say about the PERMIS side of things! :o) However, I do feel the idea is sound - it's just the implementation that brings it down. |
= PERMIS = The developer with expertise in PERMIS has shown that there is much criticism that can be directed towards the PERMIS side of things! However, he still "''feels the idea is sound - it is just the implementation that brings it down.''" |
Developer Evaluation
In February 2006 Alun Edwards (ESP-GRID) asked the developers from the BRIDGES and DyVOSE projects to answer a few brief questions to evaluate their experiences, expectations and problems (see the wider EvaluationPages).
AE started to write dev' speak in long hand, need to assimilate Femi's comments somehow. Need to ask dev to confirm contradictions exist? Used "the developers" where I/we/us was in the text but am not conviced this is always appropriate. (-- AlunEdwards [[DateTime(2006-04-11T15:19:04Z)]])
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 'contrived' 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?"
Developers' notes
What did the developers find difficult?
The operating system
The Operating System (OS) was a difficult problem. Finding a compatible platform that didn't need everything built from source - which they could never get to work. For example, finding the perfect setup that PERMIS (Privilege and Role Management Infrastructure Standards Validation) required to run correctly was difficult, (final result was Fedora Core 1, Java 1.4.2, compatible versions of their own tools working together). Fedora Core 4 did the trick though. The developers would strongly recommend a flexible attitude to OS, considering there are quite a few dependent packages that need to be installed.
xxxx AE: contradiction of Fedora Core versions? (-- AlunEdwards [[DateTime(2006-04-11T15:19:04Z)]])
The portal container
To Shibbolize the portal container was a difficult problem. Servlet containers are used to host the portal, while the Shibb must be installed to the Apache server as a module. It is very difficult to force the requests that come for the portal container through the Apache Shibboleth module first. Shibbolizing the portal container proved impossible. Fortunately, the developers used the mod_jk (Tomcat-Apache plug-in) that handles the communication between Tomcat and Apache, and provides such functionality. So Tomcat was finally chosen as the Portal container. The developers would strongly recommend that Tomcat is necessary to Shibbolize portals that require a Servlet container.
Boundaries between PERMIS and Globus
It was difficult (complicated) to understand where PERMIS stopped and Globus started – various error messages would come back sometimes referring to the PERMIS policy, sometimes the PKI authentication methods and sometimes the Globus service implementation. Working out where they were coming from could be very tricky. The supporting documentation was also pretty sparse and the source code difficult to navigate. The developers addressed this by documenting a step-by-step HOWTO going through what had been done to get it working see http://www.nesc.ac.uk/hub/projects/etf/. The developers now use their own documentation instead of the PERMIS documentation.
Find an established federation
The input that an established federation can provide proved to be invaluable in getting Shibbed in a short period of time, (days rather than weeks). In BRIDGES' case the SDSS Development Federation at EDINA ([http://sdss.ac.uk/ Shibboleth Development and Support Services (SDSS)]) normally responded to queries within 24 hours. Also the Identity Providers (IdPs) and Service Providers (SPs) can be configured and tested separately before joining them together.
xxxx AE: definition of IdP and SP correct? xxxx AE: final sentence looks like I tacked it on! (-- AlunEdwards [[DateTime(2006-04-11T15:19:04Z)]])
What makes Shibboleth a good solution for accessing a service like the BRIDGES portlet or the DyVOSE data?
Adding other projects to the infrastructure was not difficult
It is very easy to tailor attribute release/acceptance once Shibb is running. Adding other projects to the developers' infrastructure was not difficult. The developers interfaced Shibb with ?GridSphere successfully, and bypassed the ?GridSphere login to use the mod_auth_ldap authentication.
Single sign-on (SSO)
The single sign-on (SSO) capabilities of Shibb are desirable in the Grid context of BRIDGES.
A Scottish grid
Shibboleth looks quite promising especially for an academic environment where we would want to, say, give access to an application for anyone in Scotland as part of a Scottish grid. The developers would then not have to worry about managing their own user base but instead have arrangements with all other Scottish universities etc. This obviously relies on the developers' being able to trace user activity and user origin/details, for example because the National Grid Service (NGS) as an end resource dictates this to the developers under the existing agreement. So as long as they can extract a user's distinguished name (DN) programmatically from within the portal it would be a good solution for the developers. That way offending users could be tracked and hopefully dealt with at their home institution.
AE: Note from Micha "can we" extract a user's DN programmatically from within the portal?) (-- AlunEdwards [[DateTime(2006-04-11T16:39:40Z)]])
The framework is easy to use
One developer described the main benefits as flexibility, expandability, and good usability (not ease of install, but ease of use of the framework). Shibboleth greatly reduces the administration pressure for the authentication and authorisation. System administrators can easily and freely adjust user information on the Identity Provider (IdP) side without caring about the (Service Provider) SP side. On the other hand, a SP can adjust the relative policy without caring about the IdP. In this way, the administration boundary is very clear: the IdP is only responsible for the user information and information release policy, while the SP is only responsible for the authorisation policy of the resource. Also, adding or removing a particular organisation from the federation is relatively easy. There are no complex connections between an organisation and the whole framework. This feature gives the framework "good expandability".
Virtual Organisations (VOs)
Another developer explains that the technology paradigm allows distributed access to resources and provides a nice, flexible way of transferring attributes between participants in a Virtual Organisation (VO). This is a good way of limiting and exposing access to resources as and when they are needed in a VO. (However, he goes on to explain that "I'm suspicious - I think the devil will be in the implementation and it may end up being hamstrung to use only specific attributes, with the result that the flexibility will turn out to be less than it would seem.")
What issues can the developers see in a real-world production of this with 100s of users, maybe a commercial data provider, issues for the future etc.?
Almost all the developers ducked this question concentrating on scalability (see xxxx below ) instead. One did respond in detail about PERMIS (Privilege and Role Management Infrastructure Standards Validation):
PERMIS
- PERMIS is a nice idea as a policy engine that interprets SAML (Security Assertion Markup Language), but the implementation is really bad. It requires a huge supporting infrastructure of technologies that themselves can be flaky (such as requiring specific LDAP (Lightweight Directory Access Protocol) versions). The developer is not certain but as far as he knows Shibboleth is similar - it requires very specific versions of supporting technology that make it quite inflexible.
- PERMIS also provides an incredibly limited interface to use. The way it has been implemented means that a service method is run and, if it is PERMIS protected, it will either run automatically or bomb out completely with an Authorisation Exception. There is no handle, such as a parameter saying "PERMIT/DENY" that the developer can grab on to and control the flow accordingly. This led to a bit of a monumental hack in the developers' implementation of the BRIDGES code see section xxxx [, which I will expand upon in question 5] below.
PERMIS also claims to be authentication-agnostic and technically this is not a lie - but in actuality it requires a local LDAP server back-end that matches the DNs (distinguished names) used in the authentication tokens (certificates). So PERMIS is not really authentication-agnostic.
"Based on my PERMIS experience, if I was a manager of a commercial concern, I would run a country mile from implementing this. As I've said, the supporting infrastructure required is complex and I'm not convinced that the time invested in making it work was worth it."
The illusion of security
"I'm sure there are holes in PERMIS that I'm not aware of" which means that this situation "is worse than no security, it's the illusion of security."
What scalability issues can the developers identify?
Access control lists
The developers have adopted a privilege management infrastructure (the PERMIS role-based access control system for authorisation) intending to avoid scalability problems associated with Access Control Lists.
Re-writing local security policies
DyVOSE is investigating dynamic delegation, which eventually will allow separate institutions to form a Virtual Organisation (VO) without re-writing their local security policies. DyVOSE demonstrates a simplified version of this between the universities of Glasgow and Edinburgh.
User role
A problem with expanding [xxxx] is that user role which is specified by the Identity Provider (IdP) and required by the Service Provider (SP) may not be the same. So that, to access a specific grid service either the IdP have to change user role to fit to the SP specification or the will SP have to change its policy to fit the IdP. To solve this, the best way is to negotiate the relationship between roles, or unify different roles from different organizations.
[xxxx] AE insert here: grid / user base / resource? (-- AlunEdwards [[DateTime(2006-04-11T16:39:40Z)]])
PERMIS
The developer with expertise in PERMIS believes that it has not been tested for scalability in anger. When PERMIS is used with more than 10 users the developer predicts that performance will slow down chronically on any given system. This is because the code seems to be quite bloated, and this will be a problem when combined with Globus services, "which are themselves not incredibly efficient".
LDAP server back-end
The LDAP server back-end that PERMIS uses would also have to be managed automatically. The same developer is not currently aware of any tools that do this, and predicts that this would have to be a manual process anyway (because in any security process, human verification of credentials is essential at some point). Some kind of automated management tool such as this could be built, but then how would it fit in to the whole infrastructure?
Growing user base
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. Building extensibility into the system from the start would be the answer here. 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 the grid's user base is increasing.
How could the access control the developers have 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?
Firewall
Unless you tailor your firewall properly it is quite easy for someone who knows the system is there just to reference the URI : port directly to gain access to the Shibbed portal, and bypass authentication. Currently, the developers force the user request through the Apache Shib module first to do authentication, then the request is redirected to the Portal container. For example:
- A malicious user can go directly to the portal container if they know the address and port. Our portal container is located at xxx.xxx.xxx.xxx:8080, and we force user requests go to xxx.xxx.xxx.xxx:80, and then any request to the container no longer goes through 8080, instead, goes through 80. In this case, we have to block the 8080 port on the server, and only leave port 80 open.
- Another possibility is that, users manage to know the URI to the actual Grid service. This is possible - but unlikely - because the Servlet container and relative dynamic page technology are designed to prevent this from the beginning. Further, even if they know the URI of the Grid service, they would still need the JAR file of the grid service as library to invoke the service.
Such weakness must be prevented by using the firewall to block certain ports.
PERMIS
One of the major requirements to come out of the BRIDGES project was the need for usability. Biologists were simply not going to use the applications if they had to do complicated things like get UK e-Science certificates for themselves. Unfortunately, PERMIS requires PKI certificates to get the username (see xxxx authn-agnostic above). So the developers had to use a test program, to use PERMIS as a look-up system rather than integrating it completely with the BLAST service, and have the service call the URI from a specified string (this is the hack that I referred to in xxxx above). The developer with PERMIS expertise thinks this means that if anyone knows the PERMIS service URI specifically, it could be hacked - though the firewall is closed on the PERMIS server. However this is something that could be easily missed during implementation.
Public computer
If a user on a public computer does not 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.
PERMIS
The developer with expertise in PERMIS has shown that there is much criticism that can be directed towards the PERMIS side of things! However, he still "feels the idea is sound - it is just the implementation that brings it down."
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
Anthony: my involvement in this work has become fairly peripheral over the past few months, but I'll do my best. My focus was the initial hammering out of how PERMIS worked and applying this to BRIDGES - I know very little about the technicalities of Shibboleth.
- John Watt
The results can be seen below.
Results
Question |
Developer |
Answer |
1. what did you find difficult? |
|
|
|
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. |
|
Micha Bayer |
can't really comment as I was not involved in Shib-specific functionality |
|
Jipu Jiang |
As John said, the Operating System is a difficult problem. It needs no further explanation. Also, it is very difficult to force the requests that come for portal container go through the Shibb first. In another word, Shibbolise the portal container is a difficult point. As we know, servlet containers are used to host the portal, while the Shibb must be installed to the Apache server as a module. Shibbolishing the portal container is impossible except we force the requests go through the Apache Shibboleth module first. Fortunately, mod_jk is designed to connect the Apache and Tomcat, and provides such functionality. So Tomcat is finally chosen as the Portal container, and Tomcat is necessary if we want to shibbolise portals that require a Servlet container. |
|
Anthony Stell |
As John said, finding the perfect setup that PERMIS required to run correctly (Final result was Fedora Core 1, Java 1.4.2, compatible versions of their own tools working together). In terms of understanding where PERMIS stopped and Globus started was complicated too – various error messages would come back sometimes referring to the PERMIS policy, sometimes the PKI authentication methods and sometimes the Globus service implementation. Working out where they were coming from could be very tricky. The supporting documentation was also pretty sparse and the source code difficult to navigate - I addressed this by documenting a step-by-step HOWTO going through what I had done to get it working. We now use this instead of the PERMIS docs. :o) (Can all be found at http://www.nesc.ac.uk/hub/projects/etf) |
|
|
|
2. what makes Shibboleth a good solution for accessing a service like Bridges or the DyVOSE data? |
|
|
|
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. |
|
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 |
Flexibility, expandability, and good usability (here I don't mean it is easy to install, what I mean is the framework is easy to use) are the main benefits in my opinion. Shibboleth greatly reduces the administration pressure for the authentication and authorization. System administrators can easily and freely adjust user information on the IdP side without care about the SP side. On the other hand, SP can adjust the relative policy without care about the IdP. In this way, administration boundary is very clear: the IdP is only responsible for the user information and information release policy, while the SP is only responsible for the authorization policy of the resource. Also, adding or removing certain organization from the federation is relatively easy. There are no complex connection between an organization and the whole framework. This feature makes it have good expandability. |
|
Anthony Stell |
From my limited knowledge, the technology paradigm allows distributed access to resources and provides a nice, flexible way of transferring attributes between participants in a VO. This is a good way of limiting and exposing access to resources as and when they're needed in a VO. # (However, I'm suspicious - I think the devil will be in the implementation and it may end up being hamstrung to use only specific attributes, with the result that the flexibility will turn out to be less than it would seem.) |
|
|
|
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.? |
|
|
|
John Watt |
see scalability below |
|
Micha Bayer |
as in my previous point - can't think of anything else just now |
|
Jipu Jiang |
see scalability below |
|
Anthony Stell |
Um, where do I start? :o) # PERMIS is a nice idea as a policy engine that interprets SAML, but the implementation is really bad. It requires a huge supporting infrastructure of technologies that themselves can be flaky (such as requiring specific LDAP versions). As far as I know, Shibboleth is similar - it requires very specific versions of supporting technology that make it quite inflexible (but like I've said, I'm not an expert in this so don't know for sure). # PERMIS also provides an incredibly limited interface to use. The way it has been implemented means that a service method is run and, if it is PERMIS protected, it will either run automatically or bomb out completely with an Authorization Exception. There is no handle, such as a parameter saying "PERMIT/DENY" that the developer can grab on to and control the flow accordingly. This led to a bit of a monumental hack in our implementation of the BRIDGES code, which I will expand upon in question 5. # PERMIS also claims to be authentication-agnostic and *technically* this is not a lie - but in actuality it requires a local LDAP server back-end that matches the DNs used in the authentication tokens (certificates)... so it isn't really. # Based on my PERMIS experience, if I was a manager of a commercial concern, I would run a country mile from implementing this. As I've said, the supporting infrastructure required is complex and I'm not convinced that the time invested in making it work was worth it. # Plus, I'm sure there are holes that I'm not aware of => it's worse than no security, it's the illusion of security. |
|
|
|
4. what scalability issues can you identify? |
|
|
|
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 |
But it does have a problem in expanding. User Role specified by the IdP and required by the SP may not be the same. So that, to access a specific grid service, IdP have to change user role to fit to the SP specification or the other way around, SP have to change its policy to fit the IdP. To solve this, the best way is to negotiate the relationship between roles, or unify different roles from different organizations. |
|
Anthony Stell |
Though I don't know for sure, I can almost guarantee that PERMIS hasn't been tested for scalability in anger (> about 10 users). I predict that when this happens, performance will slow down chronically on any given system. The code just seems to be quite bloated, and this will be a problem when combined with Globus services, which are themselves not incredibly efficient. # The LDAP server back-end that PERMIS uses would also have to be managed automatically. I'm not aware of any tools out there that do this just now, and I think this would have to be a manual process anyway, because in any security process, human verification of credentials is essential at some point. I reckon some kind of automated management tool such as this could be built, but I'm not sure how it would fit in to the whole infrastructure. |
|
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? |
|
|
|
John Watt |
Unless you tailor your firewall properly it is quite easy for someone who knows the system is there just to reference the U R L : port [XXXX AE: written like this to cheat the wiki formatting!] 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. |
|
Micha Bayer |
the others are in a better position to anser this as this again is really Shib-specific. |
|
Jipu Jiang |
Currently, we force the user request come through the Apache Shib module first to do authentication, then the request is redirected to the Portal container. Malicious user can go directly to the portal container if they know the address and port. Such weakness must be prevented by using firewall to block certain port. For example, our portal container located at xxx.xxx.xxx.xxx:8080, and we force user requests go to xxx.xxx.xxx.xxx:80, and then any request to the container no longer go through 8080, instead, go through 80. in this case, we have to block the 8080 port on the server, and only leave port 80 open. Another possibility is that, users manage to know the URI to the actual Grid service. It is unlikely possible because the Servlet container and relative dynamic page technology are designed to prevent this from the beginning. Further, even they know the URI of the Grid service, they would still need the JAR file of the Grid service as library to invoke the service. |
|
Anthony Stell |
This is similar to John's answer. One of the major requirements to come out of the BRIDGES project was the need for usability. Biologists were simply not going to use our applications if they had to do complicated things like get UK e-Science certificates for themselves. # Unfortunately, PERMIS requires PKI certificates to get the username (see, not really authn-agnostic :o). So we had to use a test program, to use PERMIS as a look-up system rather than integrating it completely with the BLAST service, and have the service call the URI from a specified string (this is the hack that I referred to). I think this means that if anyone knows the PERMIS service URI specifically, it could be hacked - though I've closed the firewall on the PERMIS server, so it should be ok now. But it's something that could be easily missed during implementation. # As you can probably tell, I've got a fair amount of bad things to say about the PERMIS side of things! :o) However, I do feel the idea is sound - it's just the implementation that brings it down. |
Oluwafemi Ajayi's response |
step-by-step |
|
|
1. A user connects to the portal; he is redirected to SDSS (WAYF host) for single sign-on (SSO). # Shibboleth protects resources hosted on apache but our portal is hosted on Tomcat. We use mod_jk in a sense to bridge apache and tomcat so that Shibboleth can indirectly protect tomcat services. Because mod_jk allows apache to wrap tomcat services, it will be difficult for a hacker to directly access a tomcat service. In my experience, there seems not to be a performance issue for using mod_jk as a wrapper/bridge. |
|
|
2. User is redirected to the origin site for sign-on |
|
|
3. User provides authentication information through their IdP (authentication site) and a SAML authentication assertion (identity handle) is returned to the portal (service provider). # In reality, the SDSS stores a cookie on the user's browser to identify the user's IdP for single-sign-on purposes. The identity handle is also stored as a cookie on the user's browser for subsequent access to other service provider in the federation. In my own view the use of cookies poses security risks such as identity theft. # If a user turned off cookies in their browser then SSO cannot be achieved. Also if a user switches browser say from IE to Firefox, they will have to re-authenticate. # We implemented out identity provider using LDAP to provide authentication services for local users. |
|
|
4. The service provider request user attributes from the IdP using the identity handle. |
|
|
5. Ideally user's attribute certificates are returned as SAML responses to the service provider. # Our IdP releases attributes using the LDAP server we set up. The identity handle is used to query the LDAP for user attributes. # Because of the way GridSphere (Portal technology) handles data in headers, attributes are returned as "short" strings to the portal. This currently is not secured, but we are working on a better solution such as SAML assertion compression/hashing. |
|
|
6. The portal uses attributes to interact with Grid services e.g. blast service. # From our point of view there are no performance issues or further security risks from this point. |
|
|
7. Security questions really are: What do you do with attributes once exchanged at the service providers' side? What type of PMI does the service provider have? Can the PMI be driven with attributes such as Roles or DN? |
|
|
8. A none cookie solution will make current Shibboleth implementation more secure. The SSO of shib makes it a good authentication solution for services like blast but it is not enough for authorisation. A service like blast would have to be designed to do authorisation using attributes. At the moment we are pushing attributes to service providers, but a pull model is better in some scenarios (i.e. requesting attributes only when needed). |
|
|
9. At the moment (based on push mode) scalability issues lies at the Service provider, but if in pull model, services would have serious scalability issues. |
|
|
10. Security and SSO will be greatly improved if shibboleth works with OS and not browsers. |
|