[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ggf-ogsa-sec-wg] Two documents
David,
One assumption that I'm operating under is that in OGSI, applications
will often be hosted in sophisticated containers. These containers
will expose the application's interface to the world via operations
and service data (along with some operations that are generic to
container - e.g. lifetime management) and attempt to handle as much of
the security for the contained application as possible.
So when a request comes in, the container will authenticate and
authorize it (and audit, etc.) and then pass it to the application
which can then proceed with application logic. (I'm not ruling out
that an application may do it's own authorization, but I think that's
orthogonal here.)
This separation of security from application logic creates a "dumb"
PEP - it has the request with all the paramaters and all the
authentication information, but knows little about the application and
what sorts of policies it might have. I believe this will be a common
case we need to deal with.
Two other scenarios I can see driving returning policies/conditions:
* A push model, where the requestor may not know exactly what it's
request(s) is going to look like or it's going to perform a number of
request and wants to get a single assertion beforehand that allows
this.
* A PEP that has to deal with a large number of authorizations such
that it won't want to do make a call to an external service for each
instance. For example, a firewall doing filtering on SOAP
messages.
Von
David Chadwick writes (13:05 February 25, 2003):
>
>
> Von Welch wrote:
> >
> > Olle,
> >
> > This gets at one of the fundamental tensions we had when drafting
> > this - how much information to include in the request?
> >
> > One could easily imagine a very fine-grained PDP that could use the
> > whole certifiate chain and parameters of the request to render
> > decisions.
> >
> > And then one can also imagine a world with mostly coarser grained
> > PDPs that really don't want that much detail, and considering that we
> > could be talking large volumes of information in the parameters (and
> > maybe even the cert chain) shipping all this information all the time
> > could be horribly inefficient.
>
> Firstly we have to assume some intelligence in the PEP (AEF in ISO
> 10181-3 terms). It will know for example whether it is operating in push
> or pull mode. It will know what sort of application it is, and what it
> is protecting. It will therefore know (or can have built into it) what
> the policy is, and whether for example, operation parameters are used in
> the decision making or not. Consequently the PEP will know how much
> information needs to be passed to the PDP. The API should therefore
> support the passing of all possible information, but allow many fields
> to have null values, for the cases where the PEP knows that the PDP wont
> need these values.
>
> If none of the above hold true for the PEP, and the PEP is pretty dumb,
> then there seems to be no choice for it but to pass everything to the
> PDP and let it make the decision.
>
> >
> > And my guess would be that the granularity won't be consistent for
> > any PDP - for some actions it may want lots of information, for others
> > very little.
>
> I think the PEP should be able to know how much it needs to send, but if
> it sends too little, then there can be an error diagnostic meaning "more
> info required"
>
> >
> > Working under the assumption that one is not going to include all the
> > information needed in the request all of the time, there needs to be a
> > method of handling these cases when the information needed isn't
> > there. Looking around at authorization APIs one way of handling this
> > is the conditional response, where essentially you return policy to
> > the requestor for which the PDP doesn't have the necessary
> > information.
> >
>
> I think this is a bad idea in general (leaving extensibility apart,
> which is a different issue). The design should be to make things as
> simple as possible for the PEP. If the PEP is going to start to have to
> evaluate conditions, it is taking over the work that the PDP should be
> doing. We should design this so that the PDP can always make the
> decisions on behalf of the PEP (extensibility apart).
>
> Extensibility is another issue. Here, I am talking about evaluating new
> conditions that are specific to an application, and that it is not
> possible to build into a general purpose PDP. For example, Access
> allowed if user is more intelligent than previous user. Or access
> allowed if balanced diet is requested. Only the application will know
> how to evaluate these specialised conditions, and so there needs to be a
> call back mechanism to allow the application to evaluate these
> specialised conditions. But 99% of applications need never use this
> extenisibility mechanism (so it could for example be omitted from an
> initial implementation)
>
>
> > SAML Condition elements seem to be have created to fill this role.
> > So, another way of going at this would be to just include an identity
> > and then allow the response to carry a condition on it's response -
> > e.g. "Request OK, if not using a proxy with lifetime greater than 7
> > days". A requestor would then have the onus of evaluating the
> > conditions (or failing if it can't parse them).
> >
>
> I disagree here, because evaluating lifetimes is a general purpose
> evaluation that the PDP should be capable of performing. The PEP should
> simply extract the necessary parameters and pass them to the PDP for
> evaluation. Of course there is the issue of the format of the parameters
> that are passed. Should they be simple constructs like time, integer,
> string etc, or can they be complex constructs like PKCs and ACs. We have
> to decide what sorts of parameters are allowed to be passed across the
> interface.
>
> regards
>
> David
>
>
>
> > Thoughts?
> >
> > Von
> >
> > Olle Mulmo writes (11:49 February 17, 2003):
> > >
> > > A quick glance triggered a quick comment:
> > >
> > > 5.1.1 Subject Element
> > > "The SAML specification defines a URI for X.509 subject
> > > names (#X509SubjectName) that SHOULD be used for GSI authenticated identities."
> > >
> > > GSI credentials may include delegation and other assorted information
> > > that is of interest. Thus, a single subject name is often not enough.
> > > Just see various rationales for the recent GT2 authorizaiton callout
> > > extensions, that take a credential as parameter instead of a subject
> > > name.
> > >
> > > I think you should add a recommendation that people SHOULD also use the
> > > <SubjectConfirmation> element and add their binary token(s) in the
> > > <ds:keyInfo> contained in there. Except when it would be an obvious and
> > > unnecessary exercise, of course -- but it may be hard to know in what silly
> > > context a particular SAML assertion will end up in a distributed, loosely
> > > coupled world. Having a default situation in which as much tracing
> > > information as possible is provided in our tokens seems like a good thing
> > > to me.
> > >
> > > Also consider Kerberos credentials and UNIX user names: Do we reuse the
> > > SAML #emailAddress and/or #WindowsDomainQualifiedName formats? The string
> > > formats happen to be the same, but the semantics are different: it would
> > > therefore seem like an ugly hack to me. I suggest you create additional
> > > NameIdentifier format URIs for these cases.
> > >
> > > BTW, does a username without the optional domain name and no NameQualifier
> > > mean user@localhost? If so, the localhost of whom? The target or the
> > > source of the SAML document?
> > >
> > > /Olle
> > >
> > > -----Original Message-----
> > > From: owner-ogsa-sec-wg@gridforum.org
> > > [mailto:owner-ogsa-sec-wg@gridforum.org]On Behalf Of Von Welch
> > > Sent: den 15 februari 2003 21:19
> > > To: ogsa-sec-wg@gridforum.org
> > > Cc: Frank Siebenlist; Laura Pearlman; Samuel Meder
> > > Subject: [ggf-ogsa-sec-wg] Two documents
> > >
> > >
> > >
> > > All-
> > >
> > > We have a pair of documents we are submitting to you, the OGSA
> > > Security Working group, for consideration. Both of these documents
> > > represent bottom-up draft specifications of work we are actively
> > > doing. We like to get input from the community and derive GGF
> > > specifications from these drafts.
> > >
> > > The documents are:
> > >
> > > * "Use of SAML for OGSA Authorization"
> > >
> > > * "A GSSAPI profile for security context establishment and message
> > > protection using WS-SecureConversation and WS-Trust"
> > >
> > > Both of these documents have been submitted to the GGF webmaster for
> > > posting on the document page. They are also available now at:
> > >
> > > http://www.globus.org/ogsa/Security/
> > >
> > > We will also send a note to the WG chairs and ask for discussion time
> > > at GGF7.
> > >
> > > Regards,
> > >
> > > Von (for Frank, Laura, Sam and Von)
> > >
> > > p.s. I'm writing this as I pack for vacation for a week so please be
> > > sure to cc my colleagues during this time on any questions.
> > >
> > >
>
> --
> *****************************************************************
>
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> IS Institute, University of Salford, Salford M5 4WT
> Tel: +44 161 295 5351 Fax +44 01484 532930
> Mobile: +44 77 96 44 7184
> Email: D.W.Chadwick@salford.ac.uk
> Home Page: http://www.salford.ac.uk/its024/chadwick.htm
> Research Projects: http://sec.isi.salford.ac.uk
> Seminars: http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string: MLJ9-DU5T-HV8J
> PGP Key ID is 0xBC238DE5
>
> *****************************************************************begin:vcard
> n:Chadwick;David
> tel;cell:+44 77 96 44 7184
> tel;fax:+44 1484 532930
> tel;home:+44 1484 352238
> tel;work:+44 161 295 5351
> x-mozilla-html:FALSE
> url:http://www.salford.ac.uk/its024/chadwick.htm
> org:University of Salford;IS Institute
> version:2.1
> email;internet:d.w.chadwick@salford.ac.uk
> title:Professor of Information Security
> adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
> note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500: http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
> x-mozilla-cpt:;-4856
> fn:David Chadwick
> end:vcard