About
  • This user has not yet committed.

Reviews

68 active reviews

Counts may include data that you cannot access.

GuruAllan

EarlieractivityNolateractivity
GuruAllan

commented on CR-407

17 May

license is not acceptable

GuruAllan

commented on OPENAM-1275, OPENAM-1274, OPENAM-1269

30 Apr
GuruAllan

resolved OPENAM-1273

27 Apr
GuruAllan

updated the Description of OPENAM-1273

27 Apr
GuruAllan

created OPENAM-1273, OPENAM-1181

27 Apr
GuruAllan

commented on OPENAM-967

22 Nov 11
I have seen this happen on all platforms. In some cases you have to restart the web container in order to have the Modules show up.

I believe this is a caching issue
GuruAllan

changed the status to Awaiting Verification of OPENAM-916

05 Nov 11
GuruAllan

resolved OPENAM-916

05 Nov 11
GuruAllan

created OPENAM-916

05 Nov 11
GuruAllan

commented on OPENAM-892

23 Oct 11
So this sounds dangerous. the is the first instance of a service attribute we are removing....

At what point did that attribute stop being used? Will this cause any issues when we upgrade multiple servers in a replicated cluster?

GuruAllan

created OPENAM-852, OPENAM-851

04 Oct 11
GuruAllan

commented on OPENAM-846

04 Oct 11
The Adaptive Auth module is designed to be the second (or more) module in a chain. The initial module has to set the userName in the Shared state.

The adaptive Auth Module checks several (configurable) options and returns success or fail based on these.
GuruAllan

changed the Priority to 'Minor' on OPENAM-734

11 Jul 11
GuruAllan

resolved OPENAM-711

16 Jun 11
GuruAllan

created OPENAM-711

16 Jun 11
GuruAllan

commented on OPENAM-255

13 Jun 11
Added a new fix, Committed revision 829

to send a request if the doRequest attribute is set. This makes the test pass thru to Tomcat and NOT make a request if it is an SSL Socket
GuruAllan

updated 7 fields of OPENAM-182

08 Jun 11
GuruAllan

resolved OPENAM-455

04 Feb 11
GuruAllan

created OPENAM-455

04 Feb 11
GuruAllan

commented on OPENAM-220

23 Jan 11
Please look at updating the service config for Build 10, so we have a attribute in the console to edit.

The hidden value makes things quite difficult

GuruAllan

closed OPENAM-372, OPENAM-373

22 Dec 10
GuruAllan

created OPENAM-373, OPENAM-372, OPENAM-293

22 Dec 10
GuruAllan

commented on OPENAM-90

12 Aug 10
The underlying policy framework is missing the following policy:

Updating the policy will fix the issue.

In order for the DAS to work properly, this is also made a default in the templates


ssoadm create-policies -u amadmin -f .passwd -e sunamhiddenrealmdelegationservicepermissions -X ./cp.xml

Where cp.xml is:

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE Policies
    PUBLIC "-//OpenSSO 7.1 2006Q3 Admin CLI DTD//EN"
    "jar://com/sun/identity/policy/policyAdmin.dtd"
>

<Policies>
<Policy name="AgentRealmPermission" referralPolicy="false" active="true" >
    <Rule name="agent-realm-read-rule">
        <ServiceName name="sunAMDelegationService" />
        <ResourceName name="sms://*dc=opensso,dc=java,dc=net/sunAMRealmService/*" />
        <AttributeValuePair>
            <Attribute name="READ" />
            <Value>allow</Value>
        </AttributeValuePair>
    </Rule>
    <Subjects name="Subjects" description="">
        <Subject name="AuthenticatedAgents" type="AuthenticatedAgents" includeType="inclusive">
        </Subject>
    </Subjects>
</Policy>
</Policies>

GuruAllan

changed the Assignee to 'Allan Foster' on OPENAM-90

12 Aug 10
GuruAllan

finished reviewing CR-37

09 Aug 10
GuruAllan

replied to Peter Major in CR-37

09 Aug 10

It doesnt matter. Since the local variable is only used to either determine if there ARE cookies, and to generate the internalcookies, we never need to access the actual cookies field. The actual reference is from request.getCookies() which will always fetch the correct cookies

GuruAllan

created OPENAM-185, OPENAM-182

05 Aug 10
GuruAllan

resolved OPENAM-176

31 Jul 10
In Session.java, there is a method private void processSessionResponseException (SessionResponse sres,
Which in handling the session expired, tried to invalidate the appToken, causing another call to session, which ends up in a loop.

Adding an AdminToken method to invalidate the token will force the admin token to generate a new admin token which will avoid the loop.
GuruAllan

created OPENAM-176

31 Jul 10
GuruAllan

closed OPENAM-127

28 Jul 10