Developer Evaluation

Alun's first proper attempt at a chapter for evaluation of the development

In February 2006 the NeSC developers from the BRIDGES and DyVOSE projects answered the questions of the ESP-Grid project who tried to evaluate their experiences, expectations and problems during the development (see also the wider EvaluationPages). The developers included:

• Oluwafemi Ajayi
• Micha Bayer
• Jipu Jiang
• Anthony Stell
• John Watt

Contact details confirmed at http://www.nesc.ac.uk/nesc/team.html with biographies.

The developers considered 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 (including PERMIS - Privilege and Role Management Infrastructure Standards Validation), and identified for us:

1. what did you find difficult?
2. what makes Shibboleth a good solution for accessing a service like Bridges or the DyVOSE data?
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.?
4. what scalability issues can you identify?
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?

Scenario

To spark some real-world flavour a scenario was 'contrived': the developer was asked to imagine he has by chance met a manager of a faculty resource in the corridor, and he/she knows of the developer's experience and naively thinks he's the person who can just "Shibb their target..." - "This afternoon, if you've time?"

What did the developers find difficult?

In no particular order here is a summary of what the developers' recorded as being difficulties during the development:

The operating system

One problem was to find a compatible platform or operating system that did not need everything built from source, so that it all ran correctly. The developers strongly recommend a flexible attitude to operating system, considering there are quite a few dependent packages that need to be installed. Security and single sign-on (SSO) will be greatly improved if in future Shibboleth works with the operating system and not Internet browsers.

The portal container

Shibbolizing the portal container proved impossible. Servlet containers are used to host the BRIDGES portal on Tomcat, but Shibboleth protects resources hosted on Apache. It is very difficult to force the requests that come for the portal container through the Apache Shibboleth module first. The developers used the mod_jk (plug-in that handles the communication between Tomcat and Apache) so that Shibboleth can indirectly protect the Tomcat services. (Because mod_jk allows Apache to wrap Tomcat services, it will be difficult for a hacker to directly access a Tomcat service.) The developers are pleased that there does not seem to be a performance issue for using mod_jk as a wrapper/bridge. They strongly recommend that Tomcat is necessary to Shibbolize portals that require a Servlet container.

Boundaries between protocols

It was difficult (complicated) to understand where one protocol stopped and another started. Error messages would be returned - for example - referring to the PERMIS policy, or the PKI authentication methods or the Globus service implementation. Understanding where they were coming from could be very tricky. A lack of supporting documentation and difficulties navigating the source code meant the developers created their own documentation see http://www.nesc.ac.uk/hub/projects/etf/.

Find an established federation

Input from an established federation meant targets could be Shibbed in 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) could be configured and tested separately before joining them together.

Cookies

To provide authentication services for local users the developers implemented out Identity Provider - IdP (authentication site) using LDAP. The SDSS stores a cookie on the user's Internet browser to identify their IdP for single-sign-on (SSO) purposes and for subsequent access to other service providers in the federation. But if a user turned off cookies in their browser then SSO cannot be achieved. Also if a user switches browser say from Microsoft Internet Explorer to Firefox, they will have to re-authenticate.

A non-cookie solution will make current Shibboleth implementation more secure in the future. The SSO of Shibboleth 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 the developers are pushing attributes to service providers (SPs), but a pull model is better in some scenarios (i.e. requesting attributes only when needed).

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)]])

Why Shibboleth?

In no particular order here is a summary of why the developers think Shibboleth is 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 Shibboleth is running. Adding other projects to the developers' infrastructure was not difficult. The developers interfaced Shibboleth 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 Shibboleth are desirable in the Grid context of BRIDGES.

AE need to add more here, important point

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 and institutions. If a user's distinguished name (DN) can be extracted programmatically from within the portal offending users could be tracked and hopefully dealt with at their home institution. The developers are already able to trace user activity and user origin/details, (as an end resource the National Grid Service (NGS), for example, dictates this to the developers under the existing agreement).

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

Although not easy to install the main benefits of the framework are its flexibility, expandability, and ease of use. Shibboleth greatly reduces the administration load for 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)

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, once implemeted if only specific attributes have been used then this flexibility will not be evident.

of this with 100s of users, maybe a commercial data provider, issues for the future etc.? ==

Real-world production

Here are the issues (in no particular order) which the developers identified for a real-world production in the future:

PERMIS (Privilege and Role Management Infrastructure Standards Validation)

AE have I been diplomatic enough?

PERMIS is useful as a policy engine that interprets SAML (Security Assertion Markup Language), but its implementation requires a complex supporting infrastructure of specific technologies such as LDAP (Lightweight Directory Access Protocol) versions, that makes it quite inflexible and time-consuming to make it work. This may mean that it would not be an attractive solution for a commercial venture? Also the interface PERMIS provides is limited. If a service method protected by PERMIS fails to run an Authorisation Exception occurs. There is no handle, such as a parameter saying "PERMIT/DENY" that the developer can use to control the flow. In addition, although technically PERMIS is authentication-agnostic it does require a local LDAP server back-end that matches the DNs (distinguished names) used in the authentication tokens (certificates). If PERMIS is implemented poorly the developers warn that there is a danger here of the "illusion of security".

Scalability

• 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.
• 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.
• 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 must change user role to fit the SP specification or the SP must 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 organisations.

[xxxx] AE insert here: grid / user base / resource?  (-- AlunEdwards [[DateTime(2006-04-11T16:39:40Z)]])

• The PERMIS/Globus protocols may be a weakness in terms of scalability? Has it 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".

Alun got this far

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.

Push/pull model

Scalability issues lie with the service providers (SPs) in the push model described in xxxx section [xxxx insert reference to the cookies in 2.5.3]. A pull model in which attributes are requested only when needed by the SP will have serious scalability issues.

AE: this is my poor attempt at capturing Femi's point 9 (at bottom of this page) (-- AlunEdwards [[DateTime(2006-04-11T19:13:23Z)]])

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.

Cookies

In the view of at least one developer the use of cookies poses security risks such as identity theft. A cookie is stored on the user's browser to identify the user's Identity Provider (IdP) for single-sign-on (SSO) purposes. A SAML authentication assertion (identity handle), which is returned to the portal (service provider), is also stored as a cookie on the user's browser for subsequent access to other service providers in the federation.

Data in headers

Ideally user's attribute certificates are returned as SAML responses to the service provider (SP). The portal's IdP releases attributes using the LDAP server the developers 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 the developers are working on a better solution such as SAML assertion compression/hashing.

Authorisation using attributes

The BRIDGES portal uses attributes to interact with grid services e.g. BLAST. From the developers point of view there are no performance issues or further security risks from this. the security questions really are: What do you do with attributes once exchanged at the service providers' side? What type of PMI (Privilege Management Infrastructure) does the service provider have? Can the PMI be driven with attributes such as Roles or distinguished name (DN)?

AE: have AE's notes really captured what Femi is getting at, point 7 at bottom of page (-- AlunEdwards [[DateTime(2006-04-11T19:13:23Z)]])

In conclusion

Can Richard draw conclusions from a strategic viewpoint? (-- AlunEdwards [[DateTime(2006-04-11T16:57:00Z)]])

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."

---

---

---

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 has written the dev' speak in long hand. Need to ask dev to confirm contradictions exist? Used "the developers" where I/we/us was in the text but am not convinced 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:

1. what did you find difficult?
2. what makes Shibboleth a good solution for accessing a service like Bridges or the DyVOSE data?
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.?
4. what scalability issues can you identify?
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?

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?"

Need for a diplomatic version

As expected, Richard has pointed out that notes about PERMIS should not be circulated too widely. Will plan a version which is briefer, reads more snappily and removes anything to inflammatory. Note of email exchange below. (-- AlunEdwards DateTime(2006-04-18T11:14:02Z))

-------- Original Message --------
In response to Richard's message of 12/04/2006 01:44

Subject: Re: AW: Bridges and security more generally
Date: Wed, 12 Apr 2006 11:54:49 +0100
From: Alun Edwards <alun.edwards@ email address>
To: Richard Sinnott <ros@ email address>
CC: mark.norman@ email address

Hi Rich,

The notes are on the wiki as a work in progress. I am hoping that your
team have an opportunity to check the notes for accuracy - I've tried to
encapsulate 5+ opinions into the answers so I may not have done this
well in every case. Hence the need to consult your team again, if they
have time to re-read their comments.

From these notes I would like to construct "a note to future
developers". This would be the _diplomatic_ version indicating
work-arounds which work - and why they were implemented. I would plan to
do this on 18th April.

I would also like to ensure that you and your team agree with what's
written, so nothing will go to JISC/whoever until then. Indeed I was
hoping I could get you to write a short conclusion to this "note" for
future developers... but more when you see what I write!

Ally

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. Security and single sign-on (SSO) will be greatly improved if Shibboleth works with OS and not Internet browsers.

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. A user connects to the portal; he is redirected to SDSS Development Federation (WAYF host - Where Are You From) for single sign-on (SSO). Shibboleth protects resources hosted on Apache but the BRIDGES portal is hosted on Tomcat. The developers used the mod_jk (Tomcat-Apache plug-in that handles the communication between Tomcat and Apache), 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. The developers are pleased that there does not seem to be a performance issue for using mod_jk as a wrapper/bridge. 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.

Cookies

The developers implemented out Identity Provider - IdP (authentication site) using LDAP to provide authentication services for local users. Also, the SDSS stores a cookie on the user's browser to identify the user's IdP for single-sign-on (SSO) purposes. The identity handle is also stored as a cookie on the user's browser for subsequent access to other service providers in the federation. But if a user turned off cookies in their browser then SSO cannot be achieved. Also if a user switches browser say from Microsoft Internet Explorer to Firefox, they will have to re-authenticate.

A non-cookie solution will make current Shibboleth implementation more secure. The SSO of Shibboleth 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 the developers are pushing attributes to service providers (SPs), but a pull model is better in some scenarios (i.e. requesting attributes only when needed).

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.

Push/pull model

Scalability issues lie with the service providers (SPs) in the push model described in xxxx section [xxxx insert reference to the cookies in 2.5.3]. A pull model in which attributes are requested only when needed by the SP will have serious scalability issues.

AE: this is my poor attempt at capturing Femi's point 9 (at bottom of this page) (-- AlunEdwards [[DateTime(2006-04-11T19:13:23Z)]])

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.

Cookies

In the view of at least one developer the use of cookies poses security risks such as identity theft. A cookie is stored on the user's browser to identify the user's Identity Provider (IdP) for single-sign-on (SSO) purposes. A SAML authentication assertion (identity handle), which is returned to the portal (service provider), is also stored as a cookie on the user's browser for subsequent access to other service providers in the federation.

Data in headers

Ideally user's attribute certificates are returned as SAML responses to the service provider (SP). The portal's IdP releases attributes using the LDAP server the developers 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 the developers are working on a better solution such as SAML assertion compression/hashing.

Authorisation using attributes

The BRIDGES portal uses attributes to interact with grid services e.g. BLAST. From the developers point of view there are no performance issues or further security risks from this. the security questions really are: What do you do with attributes once exchanged at the service providers' side? What type of PMI (Privilege Management Infrastructure) does the service provider have? Can the PMI be driven with attributes such as Roles or distinguished name (DN)?

AE: have AE's notes really captured what Femi is getting at, point 7 at bottom of page (-- AlunEdwards [[DateTime(2006-04-11T19:13:23Z)]])

In conclusion

Can Richard draw conclusions from a strategic viewpoint? (-- AlunEdwards [[DateTime(2006-04-11T16:57:00Z)]])

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