Re: [Bodington-developers] Testing SP : groups-xml-mapper-policy

[Atif S. <BM...@bm...>]

>3) Are groups created on the fly?
>
>Come to think of it, 3) is  daft question. Of course they aren't. No  
>point creating a new group as it won't have access to anything. So  
>the mapper refers to existing groups in the bod sp. Answered my  
>question!
>
Groups are not created on the fly.  Yes the mapper refers to the 
existing groups in the bod sp.

>2) If the concept of sysadmin doesn't translate between bods then  
>we'll need a local auth option.
>
The concept of sysadmin translate between bods. This is how it translates:
Lets say user sys...@ww... comes along with following 
group attributes:
* sysadmins
* allusers
* campus.test

Lets say you have the policy file www.dev.clan.uhi.ac.uk.xml setup with 
the following content:
<bodington>
<groups-mapper-policy>
 
   <group>
        <idp-group>sysadmins</idp-group>
        <map-to>sysadmins</map-to>
    </group>
 
    <group>
        <idp-group>campus.test</idp-group>
        <map-to>campus.work</map-to>
    </group>
 
</groups-mapper-policy>
</bodington>

User sys...@ww... will be added to the following 
existing groups in the bod sp because of the above POLICY file:
* sysadmins
* campus.work
* allusers
* campus.allusers

This above method of sysadmin translattion between bods has the 
following advantages:
* More control, i.e. you decide which user from particular idp gets 
added to the sysadmin group.
    For example you could have user sys...@le... come along with 
with following group attributes:
    * sysadmins
    * allusers

Lets say you have the policy file leeds.ac.uk.xml setup with the 
following content:
<bodington>
<groups-mapper-policy> 
 
    <group>
        <idp-group>campus.test</idp-group>
        <map-to>campus.work</map-to>
    </group>
 
</groups-mapper-policy>
</bodington>

User sys...@le... will be added to the following existing groups 
in the bod sp because of the above POLICY file:
* allusers
* campus.allusers

>1) How did it know to put sys...@ww... into the  
>Bod1 sysadmins group when my mapper file was called dev.clan.uhi.ac.uk?
>  
>
Are sure sys...@ww... was added to the Bod1 sysadmins 
group when my mapper file was called dev.clan.uhi.ac.uk.xml?

If the username attribute is sys...@ww... THEN it 
would look for the mapper file: www.dev.clan.uhi.ac.uk.xml

I can't seem to replicate this behaviour you have described.
???????

>Is it possible to set it up to allow both shibb and another
>>> authentication mechanism to work at the same time?
>  
>
>
>The reason I asked was we currently have 3 authentication methods 
>(anonymous, internal and WebAuth) here at Oxford.
>
The problem is the SP guard because it protecteds the entire bodington 
i.e. : /site/*

The solution we using at leeds bio department is to have:
* SP guard protect the url /site/* , so we can do sp auth
* And have a another url /opensite/* to do the INTERNAL, X509, BASIC auth.

INTERNAL auth is the login page in bodington.

The following urls are mapped onto the same servelt i.e. 
org.bodington.servlet.BuildingServlet:
* /site/*
* /opensite/*

Ta
Atif.

p.s. sorry the email is bit long.