OGSA Security
Update and Discussion
Frank Siebenlist
The GLOBUS Project
Argonne National Laboratory
Outline
z
Introduction
– Grid Security “Problem”
z
GRAM Services Architecture
–
–
–
–
z
GT 2.0 GRAM Architecture
Lessons learnt & Requirements
OGSA-GRAM Services Architecture
=> Security Requirements
OGSA GGF5 Demo
– GSSAPI and XML-Signature/Encryption
z
OGSA & Ws-Security (Jeff Frey)
– …
z
Discussion
Grid Security “Problem”
No Cross-Domain Trust
Authentication
Authority
Authentication
Domain A
Authentication
Authority
Policy
Authority
Policy
Authority
Policy
Domain A1
Policy
Domain B1
Bridge Domain
Bridge Req
Task
Bridge
Credentials
Bridge
Credentials
secure point-topoint
Server X
Bridge Service creates ad-hoc
"Bridge Domain" to enable
secure point-to-point
Communication
Server Y
Register
Discover
Bridge Svc
Server Y
Register
& Bridge Svc
Server Y
Discovery Svc
Authentication
Domain B
Server
UID=Root
Client
GateKeeper
5. gss-accept
context
1. Client creds
10. jobrequest
(+ UID)
z
GT-2.0 GRAM Architecture
– GateKeeper (GK) is
Community Trust-Anchor
– GK runs as root
– GK “fork/su/exec”
JobManager (JM) process
– GK passes security context
– GK passes job directives
– GK passes proxy-creds
– Additional communication
requires new port
6. key-pair
generation
7. proxycert request
11. client's
UID mapping
2. GK creds
9. delegated
credentials
grid-map
file
4. gss-init
context
8. proxycert signing
UID=User
3. GateKeeper
Trust Anchor
1. GateKeeper
preparation/validation
Server
2. JobManager process
creation/hand-off
UID=Root
GateKeeper
Client
invalidated
context
Client creds
15. closed
12. export context
17. context
delegated
credentials
13. export creds
14. fork/su/exec
+ jobrequest
inherit
21. new context
18. job results
+ management
GateKeeper
Trust Anchor
GT 2.0 - GRAM Architecture
16. import context
17. context
20. new context
19. acquire creds
JobManager
UID=User
OGSA-GRAM Requirements
z
If possible…:
–
–
–
–
–
–
No privileged accounts
Minimize privileged operations
Minimize GateKeeper’s functionality/responsibility
Separate community trust-anchor from GateKeeper
End-to-end security: Client Ù JobManagerInstance
Centralize identity mapping and assertion
management for resource collections
– Single port use for all communication
– Tiered-security through configuration
– Finer grained authorization
OGSA-GRAM Services Architecture
UID=ResourcePolicyMaster
RPM-Service
JobManagerFactory
Job 1
Job 2
GSI
tp
ht
/
AP
SO
SOAP/http
GSI
JobManagerInstance
ck
ba
p
o
/lo
Job 3
JobManagerService
UID=Fred
GSI
GateKeeper
JobManagerFactory
UID=gatekeeper
GSI
start
JobManagerSvc
(setuid=root)
JobManagerService
server.acme.com
Single Gatekeeper plus JobManager/User
UID=Alice
OGSA-GRAM Services Architecture (2)
UID=RPM
Resource Policy
Master Service
UID=Fred
Job 1
Job 2
JobManagerFactory
SOAP/http
job management requires
privileged account or
setuid=root/"user"
GSI
JobManagerInstance
GateKeeper
JobManagerService
UID=GateKeeper
UID=Alice
Job 3
server.acme.com
Single Gatekeeper/JobManager Service
OGSA-GRAM Services Architecture (3)
Resource
GateKeeper
es
job directiv
e
+ JMI rout
job directives
+JMI route
job results
job results
Client
JMI-req (uid)
JobManagerService
Forwarding/
Routing Service
Secure
Gateway/
Dispatcher
jo
b
+ dir
JM ec
I r tiv
ou es
jo
te
b
re
su
lts
JMI-ref
JMIref
OK (assertion)
client name + UID
LocalJobManager
Factory
OK (assertion)
client name + UID
JMS Instantiation
JMS/JMI Identity assertion
JMS-ref
JMS-req + uid
UID (assertion)
client name (+UID)
GateKeeper Identity assertion
JobManager
ServiceFactory
tiatio
n
I-r
JM
JobManager
Factory
JobManager
Instance
JM I
Inst
an
Secure
Gateway/
Dispatcher
ID
+U
eq name
I-r
JM lient
+c
ef
)
id e
(u
q am
re n
I- ent
f
JM cli
re
+
IJM
q
e
re m
I- na
J M nt
ie
f
cl
re
+
IJM
es
tiv
ec ute
r
i
d
ro
job JMI
s
+
ul t
e
r s
job
Secure Gateway/Dispatcher
Local Identity Assertion Service
ResourcePolicyMaster
Policy Assertion Service
Security Requirements for OGSA
z
Identity assertions through community trust anchor
– End-to-end context with local resource identities
z
Translate/bridge Authentication Domains
– Host authentication vs. community authentication
z
Authorization assertions through community trust anchor
– E.g. GateKeeper role, client’s identity mapping
z
Route through different addressing domains
– Local IPC from GateKeeper to JobManagerService
z
Tunnel security context through GateKeeper
– End-to-end client-JobManagerInstance context
z
Session-based security context
– Per-message authentication too expensive
OGSA Demo-Server “Security Handlers”
OGSA-Server
GSI-Context-Handler
encrypted
reply-token
encrypted
reply-token
Transport-Handler
token-type
gsi-context-id
requester-name
port-type
Policy Enforcement
Handler
gsi-UnWrap-Handler
encrypted
request-token
request-msg
request-msg
reply-msg
reply-msg
reply-msg
Policy Enforcement
Handler
gsi-Wrap-Handler
GSI-Context-Handler
gsi-context-id
requester-name
gsi-context-id
requester-name
server-creds
GSI-Runtime
requester-name
server-creds
reply-msg
client-name
encrypted-reply-token
gsi-context-id
token-type
gsi-context-id
requester-name
Application
encrypted
request-token
requester-name
gsi-context-id
Transport-Handler
encrypted
request-token
token-type
gsi-context-id
token-type
gsi-context-id
permission
token-type
gsi-context-id
Policy Decision Point
request-msg
requester-name
gsi-context-id
ecrypted-request-token
GSI-Runtime
Context Pool
GSSAPI & XML-Signature/Encryption
z
How to leverage existing GSSAPI implementations?
– GSI, Kerberos
z
Mismatch…
– Asn.1 vs XML, transformations, canonicalization,
different pre-/post-processing
z
How to leverage XML-Signature/Encryption?
– All primitives for context negotiation, authentication,
and session conversation, but no “GSSAPI” integration
z
Tactical solution:
– Use GSSAPI for context establishment
> Wrap gss-context establishment tokens in XML-blobs
– Extract session key out of GSS-Context
> Derive keys for xml-signature/encryption
– Use XML-Signature/Encryption for session conversation
> Decorated with context identifier/time-stamp/sequence number
Requirements for Ws-Security
z
WS-Conversation
– We need session-based context
z
Ws-Policy
– Need language to communicate assertion
requirements
z
Ws-Federation
– Need language to build bridges across administrative
domains (dynamically)
z
Ws-Authorization
– Need language for access control, group/role
assertions