Re: [Acegisecurity-developer] AccessDecisionVoter interface and multiple configuration attributes
Barney,
Barney Boisvert wrote:
>With the implementation as is, UnanimousBased doesn't allow voters to
>"screw up" by voting affirmatively if they'd approve some of the
>config attributes but deny others. Since they come in one at a time,
>any denials will guaranteed to result in an overall denial. It's not
>much of a difference, but if "unanimous" means "every voter approved
>(or abstained) on every attribute", then it's mindless processing that
>the voter's don't need to deal with. Of course, if the definition of
>unanimous is different (such as "every voter must approve at least one
>attribute") then that processing is no longer assured appropriate.
>
>
I have a different (potentially incorrect) use for multiple attributes.
I have an authorization question that requires more than one piece of
information to describe. For instance, one attribute names the action
being performed and a second (optional) attribute describes the context
in which the action is taking place.
In such use, the config attributes are not separable, serializable, etc.
- they have to be considered as an ordered list in performing the
authorizaiton check.
>RoleVoter would also have to be changed if UnanimousBased changed.
>Currently it defaults to DENIED and votes GRANTED as soon as it likes
>one of the attributes. If UnanimousBased passed all config
>attributes, it'd have to do the reverse, but that would make it
>incompatible with ConsensusBased and AffirmativeBased.
>
>In reality, I think it's ConsensusBased and AffirmativeBased that
>should change, so that all config attributes are treated individually,
>rather than OR-ed together for these two, and AND-ed for
>UnanimousBased. OR-ing seems "weird" to me, and was rather confusing
>when I started my first (and only) Acegi project; AND-ing makes a lot
>more sense, at least to me.
>
>
If your suggestion is followed, I would encourage to change the vote()
method to accept ConfigAttribute argument instead of an entire
ConfigAttributeDefinition, because under the proposed scenario a voter
would never be able to consider more than one attribute.
Going back to your question as to what Unanimous means ("every voter
must approve at least one attribute" or "every voter must approve every
attribute") - I read it "as every voter must approve given attribute
configuration". From the current API the decision managers are
responsible for combining outputs of the voters, and voters are
responsible for casting votes based on all available info (that's my
read anyhow - please correct me if the intent was different). In your
proposal (and, as you point out, in the current implementation of
RoleVoter) the decision manager is responsible for both: the logic of
combining voters, and the logic of combining config attributes.
cheers,
-peter.
>On 9/25/06, Ben Alex <[EMAIL PROTECTED]> wrote:
>
>
>>Peter Kharchenko wrote:
>>
>>
>>
>>>So if I wanted to make use of a voter that needs more than one config
>>>attribute at the same time, would you recommend writing an alternate
>>>version of UnanimousBased decision manager, or is there a reason why
>>>Unanimous decision have to be done this way (and therefore I need to
>>>switch to AffermativeBase or something else) ?
>>>
>>>
>>It's pretty rare to use UnanimousBased. Most people find
>>AffirmativeBased the most useful AccessDecisionManager.
>>
>>I honestly can't remember why UnanimousBased was designed this way. It
>>was like this in the initial commit, so goes right back to March 2004
>>(if not late 2003 when I first wrote it). A good lesson why I should
>>have JavaDoced "why".
>>
>>Given I cannot see any strong justification for this behavior, I am not
>>opposed to modifying it to be consistent with ConsensusBased. The
>>UnanimousBased approach is basically a ConsensusBased approach, except
>>if any AccessDecisionVoter denies, then immediately throw
>>AccessDeniedException.
>>
>>I would want to wait until 1.1.0 before changing anything, though, in
>>case someone relies on UnanimousBased's current logic. Please feel free
>>to raise a JIRA issue if you wish.
>>
>>Cheers
>>Ben
>>
>>-
>>Take Surveys. Earn Cash. Influence the Future of IT
>>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>>opinions on IT & business topics through brief surveys -- and earn cash
>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>___
>>Home: http://acegisecurity.org
>>Acegisecurity-developer mailing list
>>Acegisecurity-developer@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
>>
>>
>>
>
>
>
>
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topi
Re: [Acegisecurity-developer] Release 1.0.2 ready
I can't right now, I'm in Munich for the Oktoberfest and I can't guarantee my accuracy ;) I'll check for your commits by the weekend in case you already started it. On 9/26/06, Ben Alex <[EMAIL PROTECTED]> wrote: > Hi all > > 1.0.2 is now ready to release. Carlos, were you still able to take care > of it? I can do so, but I won't have time for a few more days. Please > feel free to remove the reference guide and README.TXT sections that > mention JAR signing. I think we've agreed to drop it. > > Cheers > Ben > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > Home: http://acegisecurity.org > Acegisecurity-developer mailing list > Acegisecurity-developer@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] AccessDecisionVoter interface and multiple configuration attributes
With the implementation as is, UnanimousBased doesn't allow voters to "screw up" by voting affirmatively if they'd approve some of the config attributes but deny others. Since they come in one at a time, any denials will guaranteed to result in an overall denial. It's not much of a difference, but if "unanimous" means "every voter approved (or abstained) on every attribute", then it's mindless processing that the voter's don't need to deal with. Of course, if the definition of unanimous is different (such as "every voter must approve at least one attribute") then that processing is no longer assured appropriate. RoleVoter would also have to be changed if UnanimousBased changed. Currently it defaults to DENIED and votes GRANTED as soon as it likes one of the attributes. If UnanimousBased passed all config attributes, it'd have to do the reverse, but that would make it incompatible with ConsensusBased and AffirmativeBased. In reality, I think it's ConsensusBased and AffirmativeBased that should change, so that all config attributes are treated individually, rather than OR-ed together for these two, and AND-ed for UnanimousBased. OR-ing seems "weird" to me, and was rather confusing when I started my first (and only) Acegi project; AND-ing makes a lot more sense, at least to me. cheers, barneyb On 9/25/06, Ben Alex <[EMAIL PROTECTED]> wrote: > Peter Kharchenko wrote: > > > So if I wanted to make use of a voter that needs more than one config > > attribute at the same time, would you recommend writing an alternate > > version of UnanimousBased decision manager, or is there a reason why > > Unanimous decision have to be done this way (and therefore I need to > > switch to AffermativeBase or something else) ? > > It's pretty rare to use UnanimousBased. Most people find > AffirmativeBased the most useful AccessDecisionManager. > > I honestly can't remember why UnanimousBased was designed this way. It > was like this in the initial commit, so goes right back to March 2004 > (if not late 2003 when I first wrote it). A good lesson why I should > have JavaDoced "why". > > Given I cannot see any strong justification for this behavior, I am not > opposed to modifying it to be consistent with ConsensusBased. The > UnanimousBased approach is basically a ConsensusBased approach, except > if any AccessDecisionVoter denies, then immediately throw > AccessDeniedException. > > I would want to wait until 1.1.0 before changing anything, though, in > case someone relies on UnanimousBased's current logic. Please feel free > to raise a JIRA issue if you wish. > > Cheers > Ben > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > Home: http://acegisecurity.org > Acegisecurity-developer mailing list > Acegisecurity-developer@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer > -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] SEC-348
Okay, thanks! That's what I thought but since it affected a non-CAS class I wanted to be sure. -Scott Ben Alex wrote: > Scott Battaglia wrote: > >> Ben, >> >> I've been looking at SEC-348 >> > > Hi Scott > > I read through the issue in more detail and made the following comment. > I have bumped it to 1.0.3 as noted in the comment. We'll see if the > reporter provides a configuration file or more info: > > "I suspect there is a misconfiguration or misunderstanding here. With > remoting protocols in general, you don't get access to the HttpSession. > This is because most remoting protocols cannot present the assigned > jsessionid. We therefore recommend setting > HttpSessionContextIntegrationFilter.allowSessionCreation = false > (defaults to true). > > The CasAuthenticationProvider should not go back to the CAS server and > re-present the same service ticket. It seems you have a > misconfiguration, such as a missing StatelessTicketCache. > > More information can be found at > http://www.acegisecurity.org/docbook/acegi.html#cas-advanced. > > I will reassign this issue to 1.0.3, as I do not believe there is a bug > here." > > Cheers > Ben > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > Home: http://acegisecurity.org > Acegisecurity-developer mailing list > Acegisecurity-developer@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
[Acegisecurity-developer] Release 1.0.2 ready
Hi all 1.0.2 is now ready to release. Carlos, were you still able to take care of it? I can do so, but I won't have time for a few more days. Please feel free to remove the reference guide and README.TXT sections that mention JAR signing. I think we've agreed to drop it. Cheers Ben - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
