EDINA20th March 2008
EDINA Geo/Grid - Security
Prof. Richard O. Sinnott Technical Director, National e-Science Centre
University of Glasgow, [email protected]
EDINA20th March 2008
Shibboleth ScenarioService provider
ShibFrontend
5. Pass authentication info and attributes to authZ function
Grid Portal
6. Make final AuthZ decision
Grid Application
Identity Provider
Home Institution
W.A.Y.F.
Federation
User1. User points browser at Grid
resource/portal
2. Shibboleth redirects
user to W.A.Y.F. service
3.User selects their
home institution
4. Home site authenticates user and
pushes attributes to the service provider
AuthNLDAP
LDAPAuthZ
?
What sites +
attributes to
accept (trust)?
What attributes to send?
Only see/use what
allowed to?
uid
Log-in once and roam
EDINA20th March 2008
Will develop four JSR-168 compliant portlets for VO Will develop four JSR-168 compliant portlets for VO adminsadmins: :
scoped attributed management portlet (SCAMP)scoped attributed management portlet (SCAMP)
donedone
dynamic portal configuration management (CCP)dynamic portal configuration management (CCP)
e.g. configure portal content based on user e.g. configure portal content based on user privileges (security attributes)privileges (security attributes)
attribute release policies (ARP) attribute release policies (ARP) e.g. only release my VO specific attributes to VO e.g. only release my VO specific attributes to VO partnerspartners
attribute certificate portlet (ACP)attribute certificate portlet (ACP) securely push attributes out to collaborators securely push attributes out to collaborators (builds on DyVOSE project dynamic delegation of (builds on DyVOSE project dynamic delegation of authority service)authority service)
SPAM-GP PortletsSPAM-GP Portlets
EDINA20th March 2008
EDINA20th March 2008
OMII SPAM-GP project: Scoped Attribute Management Portlet (SCAMP)
OMII SPAM-GP project: Scoped Attribute Management Portlet (SCAMP)
EDINA20th March 2008
EDINA20th March 2008
EDINA20th March 2008
EDINA20th March 2008
EDINA20th March 2008
PERMIS based Authorisation checks/decisions
Glasgow Education
VO policies
Glasgow Edinburgh
Grid BLAST
DataService
Nucleotide + ProteinSequence
DB
Grid-data Client
Grid BLASTService
EdinburghEducation
VO policies
LDAP LDAP
Implemented by Students
data input
Protein/nucleotide data returned based on student team role
Glasgow SoA using Glasgow DIS to issue Edin. roles
Edinburgh SoA using Glasgow DIS to issue Edin. roles
ACs created
for Edin. roles
DyVOSE - Dynamic Privilege Management Infrastructure
OMII SPAM-GP project: ACPOMII SPAM-GP project: ACP
EDINA20th March 2008
Centralised Shibboleth Scenario + VPman project
Service provider
5. Pass authentication info and attributes to authZ function
Grid Portal
6. Make final AuthZ decision
Grid Application
Identity Provider
Home Institution
W.A.Y.F.
Federation
User1. User points browser at Grid
resource/portal
2. Shibboleth redirects
user to W.A.Y.F. service
3.User selects their
home institution
4. Home site authenticates user and
pushes attributes to the service provider
AuthNLDAP
LDAPAuthZ
VO wide
authZ
EDINA20th March 2008
VOMS
EDINA20th March 2008
VOMS
EDINA20th March 2008
Existing Demonstration(pushing attributes in
SAML)
EDINA20th March 2008
EDINA20th March 2008
EDINA20th March 2008
EDINA20th March 2008
EDINA20th March 2008
EDINA20th March 2008
EDINA20th March 2008
EDINA20th March 2008
VOMS’ing
EDINA20th March 2008
The Scenario
GT4-VOTESVOTESdiabetes
Client
GT4-VOTESVOTESdiabetes
ServicePEP OGSA-DAI
PERMISPDP
Deny/Grant
GSI-based security
DB2
DB1
DB3
VOMS Server
Voms-proxy-init VOMS credentials
VOMS PIP
collectAttribtues VOMS validated attributes
VO=nanoCmos
AuthZ request
(1) A VOTES diabetes service is deployed on a GT4 infrastructure(2) A user runs “voms-proxy-init” to generate a proxy certificate including VOMS credentials (3) and tries to invoke the protected stored procedure(4) The PEP passes the user information (including proxy certificate) to the VOMS PIP(5) VOMS PIP validates the credentials and passes back the VOMS Fully Qualified Attribute Name (FQAN) within the subject attributes. (6) The PEP calls the PERMIS PDP pushing the request information and credentials(7) The PERMIS PDP according to the policy decides if this user with certain attributes is authorized to access the service. (8) If successful the stored procedure is invoked, the federated query run and returned results joined and returned to the end user
EDINA20th March 2008
EDINA20th March 2008
Successful Nurse Interaction
Unuccessful Nurse Interaction
=> java -classpath ./build/stubs/classes/:$CLASSPATH org/globus/clients/DataFederationProxy/SecureGSNurseClient security-configRichard.xml
=>java -classpath ./build/stubs/classes/:$CLASSPATH org/globus/clients/DataFederationProxy/SecureGSDoctorClient security-configRichard.xml
EDINA20th March 2008
EDINA20th March 2008
Successful Nurse Interaction
Successful Doctor Interaction
=> java -classpath ./build/stubs/classes/:$CLASSPATH org/globus/clients/DataFederationProxy/SecureGSNurseClient security-configRichard.xml
=>java -classpath ./build/stubs/classes/:$CLASSPATH org/globus/clients/DataFederationProxy/SecureGSDoctorClient security-configRichard.xml
EDINA20th March 2008
The Scenario with Permis (VPMan)
OMII-nanoCMOSGeronimo client
OMII-nanoCMOSGeronimo ServicePEP GridSAM
PERMISPDP
OMII-PERMIS AuthZ request
Deny/Grant
SGE
NGS/ScotGrid
Condor
VOMS Server
VOMS PIP
collectAttribtues VOMS validated attributes
VO=nanoCmos
GridSAM
GridSAM
MyProxy
WS-security = Message Level Security,
1
2
3
4
5
6Subject PIP
(1) The client attempts to invoke the PERMIS protected Geronimo service. The PEP extracts the users DN and identifies that it needs attributes from a VOMS server(2) The PEP, via a Subject PIP, pulls back the relevant attributes from VOMS server (3)and passes them to the PDP(4) The permis PDP makes the decision (5) and if ok, submit job using via GridSAM to appropriate Grid Resource
Top Related