1. Säkerhet
I EJB 2.0 finns en specifikation för hur säkerhet kan hanteras. Vi börjar med att titta på hur ett anrop till en böna ser ut:
När ett anrop till en böna anländer till steg 3 (behållaren) så validerar behållaren användaren för den aktuella metoden. Vad är det som sker då behållaren ska avgöra om just denna användare har rätt att anropa denna metod hos bönan? Jo:
- Koppla metoden till roller. Först kontrollerar behållaren vilka roller som får använda metoden. Roller beskrivs av taggen <security-role> . Kopplingen mellan metod och roll hittas i taggen <method-permission> .
- Koppla användaren till roller. Användaren kallas för "principal" i EJB, och är mappad mot en eller flera roller (<security-role>). Exakt hur denna mappning går till finns inte i specen, så det är fritt för servertillverkaren att bygga sin egen lösning.
- Kontrollera att någon av användarens roller motsvarar någon av metodens roller. Om användaren innehar någon av de roller som definieras i <method-permission> så har han/hon rätt att köra metoden.
2. Sätt rättighet per metod: Kodexempel
Nedan visas ett exempel på hur du kan koppla olika metoder till rollen "salesman":
<assembly-descriptor>
<security-role>
<description>
Represents anybody who has the authority
to perform a trade.
</description>
<role-name>salesman</role-name>
</security-role>
<method-permission>
<role-name>salesman</role-name>
<method>
<ejb-name>BookingBean</ejb-name>
<method-name>*</method-name>
</method>
<method>
<ejb-name>InvoiceBean</ejb-name>
<method-name>cancelInvoice</method-name>
</method>
</method-permission>
<method-permission>
<unchecked/>
<method>
<ejb-name>ViewProductBean</ejb-name>
<method-name>*</method-name>
</method>
</method-permission>
</assembly-descriptor>
|
Lägg märke till:
- unchecked: Taggen "unchecked" betyder att alla kan använda ViewProductBean. "unchecked" ersätter taggen "role-name".
3. Run-as: Kodexempel
Ibland sker anrop mellan bönor. Tänka att en böna (böna1) anropar en annan böna (böna2). I normala fall kommer böna2 att göra validering av samma användare som blev validerad i böna1. För att ändra detta, så att alla anrop som sker från böna1 antar en viss roll kan man använda "run-as". Se exempel nedan:
<enterprise-beans>
...
<session>
<ejb-name>BookingBean</ejb-name>
...
<security-identity>
<run-as>
<role-name>admin</role-name>
</run-as>
</security-identity>
</session>
</enterprise-beans>
|
Nu kommer alla anrop från "BookingBean" till andra bönor göras med rollen "admin". Figuren nedan illustrerar då "BookingBean" gör ett anrop till "ProductBean":
4. Utnyttja isCallerInRole(): Kodexempel
Programmeraren har möjlighet att kontrollera huruvida en användare innehar en viss roll. Detta kan behövs i vissa situationer då kontroll på metodnivå inte ger tillräcklig flexibilitet. Nedan ges ett exempel:
...
if(isCallerInRole("customer") && bid.getMoney() < 1000 ){
// Caller is a Customer and has a low bid,
// therefore he is not allowed to see other bids
throw new BookingException("Caller is not valid");
}else{
// Go on..
}
...
|
För att detta ska fungera krävs att rollen "customer" finns definierad i en tagg som kallas för "security-role-ref", se exemplet nedan:
<enterprise-beans>
...
<session>
<ejb-name>BookingBean</ejb-name>
...
<security-role-ref>
<role-name>customer</role-name>
<role-link>customer</role-link>
</security-role-ref>
</session>
</enterprise-beans>
|
Se förklaring nedan:
- role-name: Taggen "role-name" är det namn som används i "isCallerInRole()".
- role-link: Taggen "role-link" läggs till av Application Assemblern för att mappa den roll som är skapad av "Bean Providern" mot den riktiga rollen. Även om samma namn används så måste ändå "role-link" finnas på plats.
5. Idéer bakom säkerhetsarkitekturen
Vilkar idéer har drivit fram den gällande säkerhetsarkitekturen:
- Underlätta för Bean provider. EJBs arkitektur uppmanar utvecklaren ("Bean provider") att inte bygga in säkerhetsregler i koden. Vem som får göra vad bestäms i ett senare skede.
- Låt Application Assembler sätta upp roller. Rollen "Application assembler" har till uppgift att skapa roller och mappa enskilda metoder mot enskilda roller.
- Underlätta för Deployern. Uppgiften att bestämma vilka användare ("principals") som ska ha vilka roller faller på "Deployern" och systemadministratören. Hur detta ska gå till bestäms ej av specen utan skiljer sig mellan olika fabrikat på applikationsservrarna.
6. Vem har ansvar för vad?
Denna bild beskriver vem som har ansvar för vad:
