Conversely, if a database is restored from archive, the associated security
information needs to be restored too.
What is really wanted is a common management interface to diverse stores of
authorization info. This interface would have to be pretty flexible though
if it is going to be able to present all the application data structures
that might need permissions associated with them.
Alex Thomas
IT Architect
Dresdner Kleinwort Benson
Windmuehlstr. 14 / 2G
D-60329 Frankfurt
> -----Original Message-----
> From: Chuck Zheng [mailto:[EMAIL PROTECTED]]
> Sent: 11 November 1999 09:21
> To: [EMAIL PROTECTED]
> Subject: Re: Possible API for Data-Related Programmatic Authorisation
>
>
> Evan,
>
> There are two problems with your suggestion:
>
> 1. It scatters security info all over the place.Should a business
> process change occur, we end up change lots of
> data, which may be used by other applications.
>
> 2. how do you manage a data used by multiple roles?
>
> cheers
> chuck
>
> Evan Ireland wrote:
>
> > Chuck,
> >
> > One simple approach is to attach role names to your data
> rows, and use
> > EJBContext.isCallerInRole(myData.role).
> >
> > Chuck Zheng wrote:
> > >
> > > Greetings,
> > >
> > > J2EE/EJB method-permission declarative security has
> simplify authorisation service.
> > > But it does not address data-related authorisation.
> This part currently has
> > > to be done by application specific programmatic security
> and it depends on programmer
> > > decipline and code-review to enforce these
> > > security checks are performed correctly.
> > >
> > > Since data-related security authorisation is such a
> common occurance, I wonder
> > > whether J2EE/EJB can provide some utilty to make it
> (semi-)automatic? Maybe
> > > JAAS/PAM will help to some extend. I think at least
> standard API can provide
> > > methods to register custom authorizer object with the J2EE/EJB
> > > framework (declaratively?) and specify the interface for
> AuthorisationData.
> > > If application can provide a AuthorisationData object at
> runtime (declarativly
> > > or programmaticly), The framework will run those registered
> > > Authoriser against the AuthorisationData object. Most of
> the time the Authoriser
> > > only need to say true/false or throw a SecurityException.
> Therefore I think
> > > this approach is very achievable - after all it is just
> like those templates
> > > in STL/RogueWave for those who use C++.
> > >
> > > Any comments?
> > >
> > > cheers
> > > chuck
> > >
> > >
> ==============================================================
> =============
> > > To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body
> > > of the message "signoff EJB-INTEREST". For general help,
> send email to
> > > [EMAIL PROTECTED] and include in the body of the
> message "help".
> >
> > --
> >
> ______________________________________________________________
> __________________
> >
> > Evan Ireland Sybase EA Server Engineering
> [EMAIL PROTECTED]
> > Wellington - New Zealand
> +64 4 934-5856
> >
> >
> ==============================================================
> =============
> > To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body
> > of the message "signoff EJB-INTEREST". For general help,
> send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
>
> ==============================================================
> =============
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body
> of the message "signoff EJB-INTEREST". For general help,
> send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
> ==============================================================
> =============
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body
> of the message "signoff EJB-INTEREST". For general help,
> send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
##########################################
This email, its content and any files transmitted with it are intended
solely for the addressee(s) and may be legally privileged and/or
confidential. Access by any other party is unauthorised without the
express written permission of the sender. If you have received this
email in error you may not copy or use the contents, attachments or
information in any way. Please destroy it and contact the sender on
the number printed above, via the Dresdner Kleinwort Benson
switchboard on +44 171 623 8000 or via e-mail return. Internet
communications are not secure unless protected using strong
cryptography. This email has been prepared using information believed
by the author to be reliable and accurate, but Dresdner Kleinwort
Benson makes no warranty as to accuracy or completeness. In particular
Dresdner Kleinwort Benson does not accept responsibility for changes
made to this email after it was sent. Any opinions expressed in this
document are those of the author and do not necessarily reflect the
opinions of the Bank or its affiliates. They may be subject to change
without notice.
##########################################
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
