[
https://issues.apache.org/jira/browse/GERONIMO-2687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505958
]
David Jencks commented on GERONIMO-2687:
----------------------------------------
Rev 548493 fixes a problem in the corba SecurityServiceInterceptor. Previously
we were sending back SAS info including something about the default subject.
The SSI no longer knows about the default subject , so we send back SAS info
with no token info inside. IMO this is better, there's no reason a caller
should be able to get any info about what kind of default subject is being
used.
> All "default" Subjects should be obtained by logging in to a realm, not
> constructed explicitly
> ----------------------------------------------------------------------------------------------
>
> Key: GERONIMO-2687
> URL: https://issues.apache.org/jira/browse/GERONIMO-2687
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: security
> Affects Versions: 2.0-M5
> Reporter: David Jencks
> Assignee: David Jencks
> Fix For: 2.0-M7
>
>
> We have several places where we just construct a Subject for a default
> principal or some such. This ties us to some very restrictive assumptions
> about what a principal is that are incompatible with e.g. triplesec. Also it
> separates security management into maintaining the login backing store (e.g.
> ldap) and maintaining the deployment plan.
> Instead, all these subjects should be obtained by logging into a realm. To
> do this we need way to supply the appropriate credentials.
> I'm thinking of an interface
> public interface CredentialStore {
> Subject getSubject(String realm, String id) throws LoginException;
> }
> that appropriate bits can use to get the subject they need. The normal
> implementation can store credentials for the ids and log in to the realm
> indicated. We can have a backwards-compatible implementation that constructs
> the subject as is done currently.
> Even better would be to have this accessible only through having some
> permissions. However this would require starting the server to require
> credentials. I'm not sure how to implement that or if it would have
> widespread support.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
