Expected Behavior If using Spring Security in-app authentication/authorization, I would like the flexibility I have when I use J2EE web.xml descriptor and in-web-container authentication/authorization. I am using LDAP (Active Directory as IP, not DAO).
I understand Spring Boot has moved from use of web.xml descriptor but I have a situation like this and I wonder if there is a workaround in Spring Boot.
Currently, most of our apps are using J2EE and in-container authentication/authorization mechanism (web containrers like OpenLiberty or similar). We are switching to Spring Boot and would prefer using in-app Spring Security authentication/authorization. But I do have one concern.
Organizations can have number of different environments they deploy applications for testing, staging, until the production. In our case we have btw 5-10 environments.
Typicaly, if I would start with a new app, I would follow these steps:
- use web.xml descriptor to define
, say I define ROLE-A, ROLE-B, ROLE-C in web.xml of my app. - once ready, hand in my application to infrastructure teams responsible for deployments to ENV1, ENV2, ENV3, ENV4, ENV5, ...
- infrastructure team would open web.xml and see
defining ROLE-A, ROLE-B, and ROLE-C - from here, infrastructure team would create server.xml file with section in which they would bind roles to users or groups. So, for ENV1, they could do something like:
<application-bnd>
<security-role name="ROLE-A">
<group name="GROUP-A" />
<user name="user1" />
<user name="user2" />
</security-role>
<security-role name="ROLE-B">
<group name="GROUP-A />
<group name="GROUP-B />
<user name="user1"/>
</security-role>
</application-bnd>
From above, they defined that - GROUP-A and user1 and user2 are mapped to ROLE-A, and - GROUP-A, GROUP-B, and user1 and mapped to ROLE-B in ENV1.
But we have multiple environments and they have different mappings. For example ENV1 has mapping like above, while ENV2 might have only mapping like:
<application-bnd>
<security-role name="ROLE-B">
<user name="user3"/>
</security-role>
</application-bnd>
, where user3 is mapped to ROLE-B. This shows why this is very flexible. It is because now, infrastructure team can add all these users to the server.env file so:
- for ENV1, server.env would have something like:
ROLE-A_USER1=user1
ROLE-A_USER2=user2
ROLE-B_USER1=user1
- for ENV2, server.env would have something like:
ROLE-B_USER3=user3
etc. This shows how infrastructure/security teams can control which users are assigned to which roles and they can also add them or remove them. The only time app needs to be changed is if a new role is added, for example ROLE-X, in which case, that role would have to be added to app web.xml. But that is all.
Obviously, roles once added change less often than users that belong to these roles and that is handled entirely by security or infrastructure teams, no development knowledge required. Devs can setup their own local instance of web-container however they want to do their work.
The above shows the flexibility of web.xml and in web-container mapping. I, as developer, define roles in the app web.xml file and hand that to infrastructure. And they
can define mapping in the web-container server.xml <application-bnd> section how to map these roles per each environment.
With Spring-Boot and in-app Spring Security handling authentication/authorization, I dont think this is possible.
I know Spring Boot uses application.properties. Perhaps I could create define app roles there instead of web.xml. However, I see no way to map these roles
to the groups and users defined in the
Curently, I do it like this
- in server.env, I have defined variables like:
ROLE-A_USER1=joe
ROLE-A_USER2=mike
ROLE-B_USER1=kevin
- in application.properties, I parametarize these to get them from server.env at run-time:
role.a.user1=${ROLE-A_USER1}
role.a.user2=${ROLE-A_USER2}
role.b.user1=${ROLE-B_USER1}
- then in app, I get these from environment like:
environment.getProperty("role.a.user1")
But as you can see this is very inpractical.
First flexibility is lost as I have to know in advance all settings on all environments' server.env files in
order to code them in my application.properties and my code when I get them using enviroment.getProperty or @Value or however.
Second, I have to code them all in my application code so I can get them
Third, if infrastructure tomorrow adds a new role ROLE-X_USER5, I have to modify the code or that role will never be accounted
Fourth, if infrastructure names a variable differently, I need to know that exact name in order to parameterize it in my application.properties
I know that in Spring Boot, I could usejee.mappableRoles(...)to pass the roles defined in the app to the web-container so it can map them to the mappings defined in server.xml <application-bnd> section.
But this would be using J2EE in-container authorization role mapping.
I wonder if there is a way to do that without involvement of J2EE and to do it entirely from within the application. This is in order to make my app web container agnostic and to use entirely Spring Security in-app authentication/authorization as we find that that removes silos mentality btw 2 teams (developers and infrastructure) and gives better understanding and easier handling of issues if something goes wrong as developer has full knowledge and ability to do modifications.
Comment From: sjohnr
@dbnex14 thanks for your detailed and thoughtful explanation. Having said that, I do not see a specific enhancement suggestion in this issue, and it feels like this is a question that would be better suited to Stack Overflow. We prefer to use GitHub issues only for bugs and enhancements.
With Spring-Boot and in-app Spring Security handling authentication/authorization, I dont think this is possible.
I don't think I agree with you that something like this is not possible. I'd be interested in exploring that, however this issue tracker is not the appropriate place to do that.
I wonder if there is a way to do that without involvement of J2EE and to do it entirely from within the application.
Would you mind performing one of the following?
a) asking a stackoverflow question and providing the link so we can take a look b) distilling the above post into a specific enhancement request c) opening a PR that demonstrates the enhancement you're thinking about
Comment From: sjohnr
It looks like possibly this question was asked a day after this ticket was opened. Was this you @dbnex14?
Comment From: dbnex14
It looks like possibly this question was asked a day after this ticket was opened. Was this you @dbnex14?
Yes
Comment From: sjohnr
It looks like the XML examples didn't make it into the question. I will go ahead and close this for now in favor of the SO question and see if I can provide any hints/help for you on that question.
Comment From: sjohnr
(I edited the question to add code blocks around the XML examples)