[OpenAM] AuthLevel

Alan Magar amagar at rogers.com
Sun Feb 20 20:57:15 GMT 2011


Mark - thanks for your help.  Yes, I have tried using those and they are giving me the "No configuration found" errors.

I am looking at forcing users to re-authenticate. Apparently this can be accomplished with ForceAuth=true.  Any idea on how to incorporate this into my agent configuration? Obviously if I include it in the OpenAM Login URL setting it will be ineffective. 

Alan



On 2011-02-20, at 3:08 PM, Mark de Reeper wrote:

> Alan,
> 
> Not attempted this sort of configuration before but there are the two Authentication Level Conditions that you can apply in a Policy definition:
> 
> - Authentication Level (greater than or equal to)
> - Authentication Level (less than or equal to)
> 
> Not sure if you are already using these but If you applied the first one to your level 2 resource you should get an Access Denied page when coming with an auth level of 1.
> 
> 
> Mark
> 
> On 21/02/2011, at 8:36 AM, Alan Magar wrote:
> 
>> I am already using the AuthContext Mappings.  I have defined levels in the Authentication Context of the SP and mapped them to the Authentication Contexts (and corresponding authentication modules) in the IdPs.  That is how the IdPs know which module to present to the user when they are redirected.  All of that works perfectly.  It is the Authentication Level condition that is not working. Is there anything else that you can think of that is required to get this working in a federated environment?
>> 
>> Alan
>> 
>> 
>> 
>> 
>> On 2011-02-20, at 2:16 PM, Allan Foster wrote:
>> 
>>> So authentication level is mapped to AuthContext in SAML.
>>> 
>>> So you can map the AuthContext on the SP and the IDP to map to the appropriate kind of auth.
>>> 
>>> In the URL,  you are sending an AuthLevel,  but you are not actually mapping that back to a specific level in your SP.  I think you will have to play with the AuthContext Mappings
>>> 
>>> Allan
>>> 
>>> On 2/20/11 11:14, Alan Magar wrote:
>>>> 
>>>> Allan,
>>>> 
>>>> Very good point.   I had the Authentication Level (greater than or equal to) condition as well but it kept giving me "No configuration found" errors when I accessed the resource.  In my federated scenario how do I get this to work?  I read something about enabling notifications on the SP.
>>>> 
>>>> Cheers,
>>>> Alan
>>>> 
>>>> 
>>>> 
>>>> On 2011-02-20, at 1:43 PM, Allan Foster wrote:
>>>> 
>>>>> Alan
>>>>> 
>>>>> So I dont see the policy that is checking authlevel?
>>>>> 
>>>>> You have an IP check,  but that only handles the unauthenticated case.  In the Authenticated case,  you are not going to redirect.  
>>>>> 
>>>>> Allan
>>>>> 
>>>>> On 2/20/11 10:40, Alan Magar wrote:
>>>>>> 
>>>>>> I have configured a simple environment with one SP and two IdPs, all of which are federated. I have also configured two web resources; level 1 and level 2. What I am trying to do is to limit access to the level 1 web resources to those with an Authentication Level of at least one and to level 2 resources to those with an Authentication Level of at least two. In my example, one IdP (idp.da.local) has level 2 authentication while the other IdP (idpb.db.local) only has level 1 authentication.
>>>>>> 
>>>>>> Within my policy for level 1 I have included the following conditions:
>>>>>> 
>>>>>> IF IP=[10.20.1.1] THEN redirectURL=http://sp.cl.gc.ca:8080/openam_s951/saml2/jsp/spSSOInit.jsp?metaAlias=/sp&idpEntityID=idp.da.local&NameIDFormat=transient&AuthLevel=1
>>>>>> IF IP=[10.30.1.1] THEN redirectURL=http://sp.cl.gc.ca:8080/openam_s951/saml2/jsp/spSSOInit.jsp?metaAlias=/sp&idpEntityID=idpb.db.local&NameIDFormat=transient&AuthLevel=1
>>>>>> 
>>>>>> Within my policy for level 2 I have included the following conditions:
>>>>>> 
>>>>>> IF IP=[10.20.1.1] THEN redirectURL=http://sp.cl.gc.ca:8080/openam_s951/saml2/jsp/spSSOInit.jsp?metaAlias=/sp&idpEntityID=idp.da.local&NameIDFormat=transient&AuthLevel=2
>>>>>> IF IP=[10.30.1.1] THEN redirectURL=http://sp.cl.gc.ca:8080/openam_s951/saml2/jsp/spSSOInit.jsp?metaAlias=/sp&idpEntityID=idpb.db.local&NameIDFormat=transient&AuthLevel=2
>>>>>> 
>>>>>> Everything works as you would expect. When I access the level 1 resource from either domain I am prompted to authenticate with the appropriate module from the appropriate IdP.  When I access the level 2 resource from domain A I am prompted to authenticate with the appropriate module.  When I access the level 2 resource from Domain B I get the error "Single Sign On failed".  Perfect.  However, if I first access the level 1 resource from Domain B and then immediately go to the level 2 resource I get access.  
>>>>>> 
>>>>>> Obviously the cookie that I am given in my initial access (to level 1) is being used to give me access to level 2. Why is the level 2 policy not denying this access?  Any thoughts on how to fix this?
>>>>>> 
>>>>>> Thanks,
>>>>>> Alan
>>>>>> 
>>>>>> _______________________________________________
>>>>>> OpenAM mailing list
>>>>>> OpenAM at forgerock.org
>>>>>> https://lists.forgerock.org/mailman/listinfo/openam
>>>>> 
>>>>> 
>>>>> -- 
>>>>> <ForgeRock-226x60.png>	 Allan Foster VP Technical Enablement
>>>>> e: allan.foster at forgerock.com
>>>>> t: +1.503.334.2546
>>>>> w: www.forgerock.com
>>>>> The New home for OpenSSO -- OpenAM! It's gonna be BIG!
>>>>> _______________________________________________
>>>>> OpenAM mailing list
>>>>> OpenAM at forgerock.org
>>>>> https://lists.forgerock.org/mailman/listinfo/openam
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OpenAM mailing list
>>>> OpenAM at forgerock.org
>>>> https://lists.forgerock.org/mailman/listinfo/openam
>>> 
>>> 
>>> -- 
>>> <ForgeRock-226x60.png>	 Allan Foster VP Technical Enablement
>>> e: allan.foster at forgerock.com
>>> t: +1.503.334.2546
>>> w: www.forgerock.com
>>> The New home for OpenSSO -- OpenAM! It's gonna be BIG!
>>> _______________________________________________
>>> OpenAM mailing list
>>> OpenAM at forgerock.org
>>> https://lists.forgerock.org/mailman/listinfo/openam
>> 
>> _______________________________________________
>> OpenAM mailing list
>> OpenAM at forgerock.org
>> https://lists.forgerock.org/mailman/listinfo/openam
> 
> _______________________________________________
> OpenAM mailing list
> OpenAM at forgerock.org
> https://lists.forgerock.org/mailman/listinfo/openam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.forgerock.org/pipermail/openam/attachments/20110220/a5dea067/attachment.html>


More information about the OpenAM mailing list