Topics

SecurityContext - downcasting getCallerPrincipal()


Arjan Tijms
 

Hi,

I noticed that in the spec text a few essentials were removed in the security context.

For instance the part here: 

https://github.com/javaee-security-spec/security-spec/commit/db51cc841e5cb3d8feedbf52e15f31a8f2420105#diff-0164c7c2792d791d98efabe67dc90021L169

Before it said:
The _getCallerPrincipal()_ method is provided to retrieve the _Principal_ that represents the caller's name. It MUST be possible for the application to downcast this _Principal_ to the exact _Principal_ type that was set by the _HttpAuthenticationMechanism_ (possibly via an _IdentityStore_) or a JASPIC _ServerAuthModule_.
But it now it just says:
The _getCallerPrincipal()_ method retrieves the _Principal_ representing the caller.
Why was the downcast part removed?

This is really important and quite an amount of people (Java EE experts even like Mark Struberg and Romain) asked for this on Twitter and elsewhere. This aspect also comes at no cost for us since JASPIC already requires it.

It would be great if this could be put back.

Thanks!

Kind regards,
Arjan Tijms


Mark Struberg
 

Hi Arjan, others!

I think that's pretty sad that this feature is about to be removed!

To say it again in all honesty: without that feature the current Principal is barely usable in real world projects!

Here is the why:

I've been working with JavaEE since a very long time and I've rarely seen the purely role based model work for real world projects.
Most of the time you need much more additional information in the Principal!
An example: Consider a governmental eHealth system.
It not only needs roles but explicit permissions.
It also knows about the tenants (multi-tenancy, here which hospitals the user works in, etc).
It might also know a 'maturity level' which is leveraged for the amount of 4-eye reviews.
E.g seniors need no review, juniors need all their customer responses reviewed by a senior, 'normal' administrating employees have a random 10% of tasks reviewed.

All this is NOT possible with just roles.

Of course one could also store this aside in some ThreadLocal etc.
But hell, why should I then use a Principal at all?
If I need to pass by some additional info anyway, then I can solely rely on that as well!

For some security integration it is possible that you can do a clean split between authentication and authorisation.
So the LoginModule would do the authentication and effectively just pass the userName.
And all the other info (the authorisation) is e.g. resolved in a ServletFilter.
That works fine in practice - but again: most of the times the overhead with the LoginModule or JASPIC is just not worth it.

But in some cases you simply cannot split authentication and authorisation. Think about Oauth2+JWT.
Here the authorisation is contained in the JWT. It would be pretty nuts to parse this twice...

TL;DR (or 'management summary' for the elder of us):
All the JASPIC/LoginModule etc stuff is imo only worth if I get access to the FULL Principal in my application!

Or can anybody explain to me how else it should work?
Did I miss something?

txs and LieGrue,
strub


Werner Keil
 

Mark,

Thanks for the input. Glad there is some discussion especially in the not yet final Java EE 8 JSRs as I suggested in yesterday's interview with SouJava.

Could you elaborate this a little more e.g. also some "pseudo Code" showing the need for both.

Especially the "admin" vs. "standard user" seems pretty well covered via roles.

Kind Regards,
Werner


Mark Struberg
 

Pretty easy.
Imagine that your application needs a tenant information for the logged in user.
And depending on the tenant you can of course read different parts of the underlying data.


Werner Keil
 

First of all, at the moment in the master branch SecurityContext has a method
Principal getCallerPrincipal();

So exposing it as CallerPrincipal is gone, but not the entire method as such.
It may seem a bit ugly to some, but doing something like

if (context.getCallerPrincipal() instanceof CallerPrincipal) {
CallerPrincipal cp = (CallerPrincipal) context.getCallerPrincipal();
}

Would do the whole trick. 

IMO if the method must return Principal for whatever reason (e.g. extensibility with different Principal implementations) could we call it getPrincipal because that's exactly what it returns. Or return CallerPrincipal again, otherwise the API causes irritation with the exact type in the same package right next to it but returning its parent interface.

WDYT?

Werner


Arjan Tijms
 

Hi,

On Mon, May 29, 2017 at 9:38 PM, Werner Keil <werner.keil@...> wrote:
First of all, at the moment in the master branch SecurityContext has a method
Principal getCallerPrincipal();

So exposing it as CallerPrincipal is gone, but not the entire method as such.
It may seem a bit ugly to some, but doing something like

if (context.getCallerPrincipal() instanceof CallerPrincipal) {
CallerPrincipal cp = (CallerPrincipal) context.getCallerPrincipal();
}

Would do the whole trick. 


That's exactly the intention of how it was specified ;)

However, Will argued that this method should be able to return WLSPrincipal (https://docs.oracle.com/cd/E11035_01/wls100/javadocs/weblogic/security/principal/WLSPrincipal.html), which is a type specific for WebLogic, without necessarily having the ability to get back CallerPrincipal or any other custom Principal.

The only thing preserved in that vision would be the name. So if you put in a CallerPrincipal with name "joe", then the output would be a WLSPrincipal, with the only guarantee that calling getName() on it returns "joe"

In other words 

if (context.getCallerPrincipal() instanceof CallerPrincipal) {
   // Can't reach this, Principal would not of type CallerPrincipal
}

But on WebLogic:

if (context.getCallerPrincipal() instanceof WLSPrincipal ) {
   // We get here on WebLogic, but obviously not on JBoss
}

Hope this makes it more clear.

Kind regards,
Arjan Tijms




 

IMO if the method must return Principal for whatever reason (e.g. extensibility with different Principal implementations) could we call it getPrincipal because that's exactly what it returns. Or return CallerPrincipal again, otherwise the API causes irritation with the exact type in the same package right next to it but returning its parent interface.

WDYT?

Werner



Werner Keil
 

I understand the intention. And if Principal was implemented in product-specific ways for nearly 20 years now, there probably is no nicer or cleaner way around it.

However
On Mon, May 29, 2017 at 02:37 pm, Arjan Tijms wrote:
if (context.getCallerPrincipal() instanceof CallerPrincipal) {
   // Can't reach this, Principal would not of type CallerPrincipal
}

Is just weird if you have a method getCallerPrincipal() and it does not return a CallerPrincipal.
Either we can find a better name for that API element than CallerPrincipal or  the method should have been renamed the monent its return type was changed. To getPrincipal() or something as generic. The method name should be self-descriptive and not tie itself to one case.

Just a somewhat older example in Struts http://www.d.umn.edu/~tcolburn/cs4531/struts/api/org/apache/struts/action/DynaActionForm.html
There's a method called getMap(). Of course it'll return all kinds of implementations including HashMap, but it wasn't called getHashMap() there either.

Kind Regards,
Werner


Arjan Tijms
 

Hi,

On Tuesday, May 30, 2017, Werner Keil <werner.keil@...> wrote:
I understand the intention. And if Principal was implemented in product-specific ways for nearly 20 years now, there probably is no nicer or cleaner way around it.


Only WebLogic has problems with it (according to Will).

JASPIC already requires that it at least must be possible to return the exact principal.

Kind regards,
Arjan Tijms



 

However
On Mon, May 29, 2017 at 02:37 pm, Arjan Tijms wrote:
if (context.getCallerPrincipal() instanceof CallerPrincipal) {
   // Can't reach this, Principal would not of type CallerPrincipal
}

Is just weird if you have a method getCallerPrincipal() and it does not return a CallerPrincipal.
Either we can find a better name for that API element than CallerPrincipal or  the method should have been renamed the monent its return type was changed. To getPrincipal() or something as generic. The method name should be self-descriptive and not tie itself to one case.

Just a somewhat older example in Struts http://www.d.umn.edu/~tcolburn/cs4531/struts/api/org/apache/struts/action/DynaActionForm.html
There's a method called getMap(). Of course it'll return all kinds of implementations including HashMap, but it wasn't called getHashMap() there either.

Kind Regards,
Werner


Werner Keil
 

Well, it's ultimately Will's decision, if the "ugly hack" for Weblogic (which of course is of importance to Oracle;-) would be a reason to keep the name and hope, in a future version WLS could be upgraded and the type changed at that point. Then and only then I would understand the current naming.

Kind Regards,
Werner


Guillermo González de Agüero
 

Hi,

Not exactly the same, but the CDI spec has another issue related to accessing the original Principal object: https://issues.jboss.org/browse/CDI-597

I think it's obvious that this is a needed feature and if JASPIC already mandates it, it shouldn't be a problem for any certified server.

Hopefully we can reach a solution that satisfies everybody here.


Regards,

Guillermo González de Agüero

El mar., 30 de mayo de 2017 11:06, Werner Keil <werner.keil@...> escribió:
Well, it's ultimately Will's decision, if the "ugly hack" for Weblogic (which of course is of importance to Oracle;-) would be a reason to keep the name and hope, in a future version WLS could be upgraded and the type changed at that point. Then and only then I would understand the current naming.

Kind Regards,
Werner


Will Hopkins
 

I don't have time now to investigate what CDI is proposing to standardize w.r.t. Principals, but I hope they aren't creating a parallel security API that imposes requirements on the security runtime with respect to principals, etc.

I don't want to directly respond to each of the previous messages in this thread, but I'll try to address the points made in summary fashion. I've been thinking about this some more, and I have a proposal I think might meet everyone's needs.

First, thank-you, Mark, for providing some real-world examples. There is more than one way to address your use case, but I agree that using a custom Principal type is a reasonable approach. In fact, WebLogic's native principal types have extra fields as well, for similar reasons -- we can carry a GUID, and an identity domain (like a tenant ID), in addition to user/group name.

I'm not opposed to specifying that custom principals must be allowed -- I removed the existing language to try and get clarity about what the real requirement is, and to see if it could be specified in a way that makes sense both for app developers, and for platform vendors.

To that end, I think the question really becomes, what does it mean to be the "caller principal", or the "distinguished principal"?

It's clear that applications have need of custom principal types. Hopefully it's equally clear that container implementations -- most or all of them, not just WebLogic -- need to be able to rely on certain properties of "user" and "group" principals in order for the platform to provide secure and functional identity and authorization services. JASPIC explicitly recognizes this by providing a CallerPrincipalCallback and a GroupPrincipalCallback, the function of which is "to set the container's representation of the caller principal".

I don't think those requirements are mutually exclusive. We just need to be able to specify the purpose and function of the various principals that might be in a Subject, from the POV of both the application developer and the platform vendor.

Here is a strawman proposal for how we could do that:
  • The "caller" and "group" principal types are determined by the platform vendor, and can be designed to provide vendor-specific functionality, but must logically represent the caller's identity, and the groups (if any) that the caller belongs to.
  • HAM authors (and perhaps SAM authors?) MUST handle CallerPrincipalCallback and (if groups are present) GroupPrincipalCallback.
  • HAM authors (and perhaps SAM authors?) MAY add additional principals off whatever type they choose.
That above gets us 1/2 way there. It does potentially mean that the caller "name" is represented in two principals -- the platform caller principala, and an app-supplied custom principal, but that seems like a fairly minor issue.

The next question is whether a principal provided by the application (HAM, SAM, etc.) needs to be "distinguished" in the caller's Subject, and, if so, how:
  • We could define a "distinguished" principal as being the app's version of a "caller" principal, where the caller principal is always determined by the platform. That principal could be accessed by calling, say, "SecurityContext.getDistinguishedPrincipal()". But this approach would require another callback to notify the container what the distinguished principal was, and the container would have to figure out a way to remember that information in the Subject.
  • Another approach would be to provide a "SecurityContext.getPrincipalByType(Class <? extends Principal> pType)", that would return any principal (or principals) of a specific type from the caller's Subject. That would seemingly be just as good -- for application-specific principals, the calling code would likely know at least the base type of the desired principal.
  • Lastly, we could provide an accessor for the caller's Subject:  "SecurityContext.getCallerSubject()", and let the application root around in the Subject itself.
Would any of the above be acceptable approaches for providing access to custom principals provided by a HAM or SAM? The container would be expected to include both the platform caller/group principals and the application-specific principals in the Subject, so that the set of principals used to evaluate permissions (and handle JACC authorization) would include all principals supplied by the HAM/SAM, and potentially others as well.

What do people think?

Regards,

Will


On 05/30/2017 03:05 PM, Guillermo González de Agüero wrote:
Hi,

Not exactly the same, but the CDI spec has another issue related to accessing the original Principal object: https://issues.jboss.org/browse/CDI-597

I think it's obvious that this is a needed feature and if JASPIC already mandates it, it shouldn't be a problem for any certified server.

Hopefully we can reach a solution that satisfies everybody here.


Regards,

Guillermo González de Agüero

El mar., 30 de mayo de 2017 11:06, Werner Keil <werner.keil@...> escribió:
Well, it's ultimately Will's decision, if the "ugly hack" for Weblogic (which of course is of importance to Oracle;-) would be a reason to keep the name and hope, in a future version WLS could be upgraded and the type changed at that point. Then and only then I would understand the current naming.

Kind Regards,
Werner

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Guillermo González de Agüero
 

Hi,


On Wed, May 31, 2017 at 2:39 AM, Will Hopkins <will.hopkins@...> wrote:
I don't have time now to investigate what CDI is proposing to standardize w.r.t. Principals, but I hope they aren't creating a parallel security API that imposes requirements on the security runtime with respect to principals, etc.
No, don't worry. CDI provides an injectable Principal bean, and Romain asks for a way to get the original Principal object, as CDI gives a proxy which can't be downcasted. It was just another example of someone in need of the original implementation. Sorry if it was confusing.


I don't want to directly respond to each of the previous messages in this thread, but I'll try to address the points made in summary fashion. I've been thinking about this some more, and I have a proposal I think might meet everyone's needs.

First, thank-you, Mark, for providing some real-world examples. There is more than one way to address your use case, but I agree that using a custom Principal type is a reasonable approach. In fact, WebLogic's native principal types have extra fields as well, for similar reasons -- we can carry a GUID, and an identity domain (like a tenant ID), in addition to user/group name.

I'm not opposed to specifying that custom principals must be allowed -- I removed the existing language to try and get clarity about what the real requirement is, and to see if it could be specified in a way that makes sense both for app developers, and for platform vendors.

To that end, I think the question really becomes, what does it mean to be the "caller principal", or the "distinguished principal"?

It's clear that applications have need of custom principal types. Hopefully it's equally clear that container implementations -- most or all of them, not just WebLogic -- need to be able to rely on certain properties of "user" and "group" principals in order for the platform to provide secure and functional identity and authorization services. JASPIC explicitly recognizes this by providing a CallerPrincipalCallback and a GroupPrincipalCallback, the function of which is "to set the container's representation of the caller principal".

I don't think those requirements are mutually exclusive. We just need to be able to specify the purpose and function of the various principals that might be in a Subject, from the POV of both the application developer and the platform vendor.

Here is a strawman proposal for how we could do that:
  • The "caller" and "group" principal types are determined by the platform vendor, and can be designed to provide vendor-specific functionality, but must logically represent the caller's identity, and the groups (if any) that the caller belongs to.
  • HAM authors (and perhaps SAM authors?) MUST handle CallerPrincipalCallback and (if groups are present) GroupPrincipalCallback.
  • HAM authors (and perhaps SAM authors?) MAY add additional principals off whatever type they choose.
That above gets us 1/2 way there. It does potentially mean that the caller "name" is represented in two principals -- the platform caller principala, and an app-supplied custom principal, but that seems like a fairly minor issue.

The next question is whether a principal provided by the application (HAM, SAM, etc.) needs to be "distinguished" in the caller's Subject, and, if so, how:
  • We could define a "distinguished" principal as being the app's version of a "caller" principal, where the caller principal is always determined by the platform. That principal could be accessed by calling, say, "SecurityContext.getDistinguishedPrincipal()". But this approach would require another callback to notify the container what the distinguished principal was, and the container would have to figure out a way to remember that information in the Subject.
  • Another approach would be to provide a "SecurityContext.getPrincipalByType(Class <? extends Principal> pType)", that would return any principal (or principals) of a specific type from the caller's Subject. That would seemingly be just as good -- for application-specific principals, the calling code would likely know at least the base type of the desired principal.
  • Lastly, we could provide an accessor for the caller's Subject:  "SecurityContext.getCallerSubject()", and let the application root around in the Subject itself.
I'm definitely not an expert in the field, but I think this getCallerSubject() method could be a nice addition (aside from any other potentially added methods).
Would any of the above be acceptable approaches for providing access to custom principals provided by a HAM or SAM? The container would be expected to include both the platform caller/group principals and the application-specific principals in the Subject, so that the set of principals used to evaluate permissions (and handle JACC authorization) would include all principals supplied by the HAM/SAM, and potentially others as well.

What do people think?

Regards,

Will


On 05/30/2017 03:05 PM, Guillermo González de Agüero wrote:
Hi,

Not exactly the same, but the CDI spec has another issue related to accessing the original Principal object: https://issues.jboss.org/browse/CDI-597

I think it's obvious that this is a needed feature and if JASPIC already mandates it, it shouldn't be a problem for any certified server.

Hopefully we can reach a solution that satisfies everybody here.


Regards,

Guillermo González de Agüero

El mar., 30 de mayo de 2017 11:06, Werner Keil <werner.keil@...> escribió:
Well, it's ultimately Will's decision, if the "ugly hack" for Weblogic (which of course is of importance to Oracle;-) would be a reason to keep the name and hope, in a future version WLS could be upgraded and the type changed at that point. Then and only then I would understand the current naming.

Kind Regards,
Werner

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Mark Struberg
 

Per CDI spec we provide a producer for exactly the Principal it gets from the Container.
It does not define that it is upcastable.

This is as 'thin' as
"a bean with bean type java.security.Principal, allowing injection of a Principal representing the current caller identity"

In fact for most containers it historically was not possible to get back to any custom Principle.

LieGrue,
strub (with my CDI EG hat on)

Am 31.05.2017 um 02:39 schrieb Will Hopkins <will.hopkins@oracle.com>:

I don't have time now to investigate what CDI is proposing to standardize w.r.t. Principals, but I hope they aren't creating a parallel security API that imposes requirements on the security runtime with respect to principals, etc.

I don't want to directly respond to each of the previous messages in this thread, but I'll try to address the points made in summary fashion. I've been thinking about this some more, and I have a proposal I think might meet everyone's needs.

First, thank-you, Mark, for providing some real-world examples. There is more than one way to address your use case, but I agree that using a custom Principal type is a reasonable approach. In fact, WebLogic's native principal types have extra fields as well, for similar reasons -- we can carry a GUID, and an identity domain (like a tenant ID), in addition to user/group name.

I'm not opposed to specifying that custom principals must be allowed -- I removed the existing language to try and get clarity about what the real requirement is, and to see if it could be specified in a way that makes sense both for app developers, and for platform vendors.

To that end, I think the question really becomes, what does it mean to be the "caller principal", or the "distinguished principal"?

It's clear that applications have need of custom principal types. Hopefully it's equally clear that container implementations -- most or all of them, not just WebLogic -- need to be able to rely on certain properties of "user" and "group" principals in order for the platform to provide secure and functional identity and authorization services. JASPIC explicitly recognizes this by providing a CallerPrincipalCallback and a GroupPrincipalCallback, the function of which is "to set the container's representation of the caller principal".

I don't think those requirements are mutually exclusive. We just need to be able to specify the purpose and function of the various principals that might be in a Subject, from the POV of both the application developer and the platform vendor.

Here is a strawman proposal for how we could do that:
• The "caller" and "group" principal types are determined by the platform vendor, and can be designed to provide vendor-specific functionality, but must logically represent the caller's identity, and the groups (if any) that the caller belongs to.
• HAM authors (and perhaps SAM authors?) MUST handle CallerPrincipalCallback and (if groups are present) GroupPrincipalCallback.
• HAM authors (and perhaps SAM authors?) MAY add additional principals off whatever type they choose.
That above gets us 1/2 way there. It does potentially mean that the caller "name" is represented in two principals -- the platform caller principala, and an app-supplied custom principal, but that seems like a fairly minor issue.

The next question is whether a principal provided by the application (HAM, SAM, etc.) needs to be "distinguished" in the caller's Subject, and, if so, how:
• We could define a "distinguished" principal as being the app's version of a "caller" principal, where the caller principal is always determined by the platform. That principal could be accessed by calling, say, "SecurityContext.getDistinguishedPrincipal()". But this approach would require another callback to notify the container what the distinguished principal was, and the container would have to figure out a way to remember that information in the Subject.
• Another approach would be to provide a "SecurityContext.getPrincipalByType(Class <? extends Principal> pType)", that would return any principal (or principals) of a specific type from the caller's Subject. That would seemingly be just as good -- for application-specific principals, the calling code would likely know at least the base type of the desired principal.
• Lastly, we could provide an accessor for the caller's Subject: "SecurityContext.getCallerSubject()", and let the application root around in the Subject itself.
Would any of the above be acceptable approaches for providing access to custom principals provided by a HAM or SAM? The container would be expected to include both the platform caller/group principals and the application-specific principals in the Subject, so that the set of principals used to evaluate permissions (and handle JACC authorization) would include all principals supplied by the HAM/SAM, and potentially others as well.

What do people think?

Regards,

Will


On 05/30/2017 03:05 PM, Guillermo González de Agüero wrote:
Hi,

Not exactly the same, but the CDI spec has another issue related to accessing the original Principal object: https://issues.jboss.org/browse/CDI-597

I think it's obvious that this is a needed feature and if JASPIC already mandates it, it shouldn't be a problem for any certified server.

Hopefully we can reach a solution that satisfies everybody here.


Regards,

Guillermo González de Agüero

El mar., 30 de mayo de 2017 11:06, Werner Keil <werner.keil@gmail.com> escribió:
Well, it's ultimately Will's decision, if the "ugly hack" for Weblogic (which of course is of importance to Oracle;-) would be a reason to keep the name and hope, in a future version WLS could be upgraded and the type changed at that point. Then and only then I would understand the current naming.

Kind Regards,
Werner
--
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Rudy De Busscher
 

I find the 
"SecurityContext.getPrincipalByType(Class <? extends Principal> pType)"
A good idea.

Some other frameworks (like Apache Shiro) use the same concept.
- User/Caller is identified by a Collection of Principals
- You have a primary principal, returned when you call getCallerPrincipal (or equivalent)
- You can retrieve the complete Collection or a specific type (if existent) by getPrincipalByType()



On 31 May 2017 at 02:39, Will Hopkins <will.hopkins@...> wrote:
I don't have time now to investigate what CDI is proposing to standardize w.r.t. Principals, but I hope they aren't creating a parallel security API that imposes requirements on the security runtime with respect to principals, etc.

I don't want to directly respond to each of the previous messages in this thread, but I'll try to address the points made in summary fashion. I've been thinking about this some more, and I have a proposal I think might meet everyone's needs.

First, thank-you, Mark, for providing some real-world examples. There is more than one way to address your use case, but I agree that using a custom Principal type is a reasonable approach. In fact, WebLogic's native principal types have extra fields as well, for similar reasons -- we can carry a GUID, and an identity domain (like a tenant ID), in addition to user/group name.

I'm not opposed to specifying that custom principals must be allowed -- I removed the existing language to try and get clarity about what the real requirement is, and to see if it could be specified in a way that makes sense both for app developers, and for platform vendors.

To that end, I think the question really becomes, what does it mean to be the "caller principal", or the "distinguished principal"?

It's clear that applications have need of custom principal types. Hopefully it's equally clear that container implementations -- most or all of them, not just WebLogic -- need to be able to rely on certain properties of "user" and "group" principals in order for the platform to provide secure and functional identity and authorization services. JASPIC explicitly recognizes this by providing a CallerPrincipalCallback and a GroupPrincipalCallback, the function of which is "to set the container's representation of the caller principal".

I don't think those requirements are mutually exclusive. We just need to be able to specify the purpose and function of the various principals that might be in a Subject, from the POV of both the application developer and the platform vendor.

Here is a strawman proposal for how we could do that:
  • The "caller" and "group" principal types are determined by the platform vendor, and can be designed to provide vendor-specific functionality, but must logically represent the caller's identity, and the groups (if any) that the caller belongs to.
  • HAM authors (and perhaps SAM authors?) MUST handle CallerPrincipalCallback and (if groups are present) GroupPrincipalCallback.
  • HAM authors (and perhaps SAM authors?) MAY add additional principals off whatever type they choose.
That above gets us 1/2 way there. It does potentially mean that the caller "name" is represented in two principals -- the platform caller principala, and an app-supplied custom principal, but that seems like a fairly minor issue.

The next question is whether a principal provided by the application (HAM, SAM, etc.) needs to be "distinguished" in the caller's Subject, and, if so, how:
  • We could define a "distinguished" principal as being the app's version of a "caller" principal, where the caller principal is always determined by the platform. That principal could be accessed by calling, say, "SecurityContext.getDistinguishedPrincipal()". But this approach would require another callback to notify the container what the distinguished principal was, and the container would have to figure out a way to remember that information in the Subject.
  • Another approach would be to provide a "SecurityContext.getPrincipalByType(Class <? extends Principal> pType)", that would return any principal (or principals) of a specific type from the caller's Subject. That would seemingly be just as good -- for application-specific principals, the calling code would likely know at least the base type of the desired principal.
  • Lastly, we could provide an accessor for the caller's Subject:  "SecurityContext.getCallerSubject()", and let the application root around in the Subject itself.
Would any of the above be acceptable approaches for providing access to custom principals provided by a HAM or SAM? The container would be expected to include both the platform caller/group principals and the application-specific principals in the Subject, so that the set of principals used to evaluate permissions (and handle JACC authorization) would include all principals supplied by the HAM/SAM, and potentially others as well.

What do people think?

Regards,

Will


On 05/30/2017 03:05 PM, Guillermo González de Agüero wrote:
Hi,

Not exactly the same, but the CDI spec has another issue related to accessing the original Principal object: https://issues.jboss.org/browse/CDI-597

I think it's obvious that this is a needed feature and if JASPIC already mandates it, it shouldn't be a problem for any certified server.

Hopefully we can reach a solution that satisfies everybody here.


Regards,

Guillermo González de Agüero

El mar., 30 de mayo de 2017 11:06, Werner Keil <werner.keil@...> escribió:
Well, it's ultimately Will's decision, if the "ugly hack" for Weblogic (which of course is of importance to Oracle;-) would be a reason to keep the name and hope, in a future version WLS could be upgraded and the type changed at that point. Then and only then I would understand the current naming.

Kind Regards,
Werner

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803



Werner Keil
 

Looks good to me as well.

Would that replace the no-op version currently named getCallerPrincipal() ?

Werner


Mark Struberg
 

This might also be named in analogue what we have in JPA and Bean Validation, etc:
T unwrap(Class<T>)

We should imo try to keep EE parts as homogenous as possible.

LieGrue,
strub

Am 31.05.2017 um 12:06 schrieb Werner Keil <werner.keil@gmail.com>:

Looks good to me as well.

Would that replace the no-op version currently named getCallerPrincipal() ?

Werner


Arjan Tijms
 

I mentioned JPA and that method already ;)

I do wonder where to place unWrap then, as just Principal can't be extended (Java SE type). What we could do for instance is; make the return type getCallerPrincipal as Werner mentioned:


CallerPrincipal callerPrincipal = SecurityContext.getCallerPrincipal();


This CallerPrincipal is NOT the exact Principal set by the HAM or SAM, but only has the same output for getName(). Then, as Mark and Rudy proposed, this type has the unwrap method for the actual type:


MyPrincipal myPrincipal = callerPrincipal.unwrap(MyPrincipal.class);


And it can be used for the functionality Will needed:


WLSPrincipal wlsPrincipal = callerPrincipal.unwrap(WLSPrincipal.class);


Optionally, we could provide 2 convenience methods:


// Return whatever (unknown) principal the HAM or SAM set
Principal myPrincipal = callerPrincipal.getOriginalPrincipal();

// Return whatever (unknown) principal WebLogic used internally
Principal wlsPrincipal = callerPrincipal.getContainerPrincipal();


Contrary to what Will raised as potential concern, the CallerPrincipal does not have to be necessarily present in the Subject. For now WebLogic *could* do (but does not have to do):

class SecurityContextImpl implements SecurityContext {
    
    // ...

    public CallerPrincipal getCallerPrincipal() {
        WLSPrincipal wlsPrincipal = ... get from somewhere
        Principal originalPrincipal = ... get from somewhere

        return new CallerPrincipalImpl(originalPrincipal, wlsPrincipal);
    }
}

Thoughts?

Kind regards,
Arjan Tijms















On Wed, May 31, 2017 at 12:19 PM, Mark Struberg via Groups.Io <struberg@...> wrote:
This might also be named in analogue what we have in JPA and Bean Validation, etc:
T unwrap(Class<T>)

We should imo try to keep EE parts as homogenous as possible.

LieGrue,
strub

> Am 31.05.2017 um 12:06 schrieb Werner Keil <werner.keil@...>:
>
> Looks good to me as well.
>
> Would that replace the no-op version currently named getCallerPrincipal() ?
>
> Werner
>






Will Hopkins
 

Hi Guillermo,

On 05/31/2017 02:03 AM, Guillermo González de Agüero wrote:

No, don't worry. CDI provides an injectable Principal bean, and Romain asks for a way to get the original Principal object, as CDI gives a proxy which can't be downcasted. It was just another example of someone in need of the original implementation. Sorry if it was confusing.
Where does the Principal bean come from in the first instance? Is it provided/instantiated by the container? If so, what Principal does it represent, and how is that Principal obtained?

I'm definitely not an expert in the field, but I think this getCallerSubject() method could be a nice addition (aside from any other potentially added methods).
Agreed.

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Will Hopkins
 

Hi Mark,

On 05/31/2017 02:52 AM, Mark Struberg via Groups.Io wrote:
Per CDI spec we provide a producer for exactly the Principal it gets from the Container.
It does not define that it is upcastable.

This is as 'thin' as 
"a bean with bean type java.security.Principal, allowing injection of a Principal representing the current caller identity"

In fact for most containers it historically was not possible to get back to any custom Principle.

Sounds like, in effect, it's a new security API -- providing access to the current authenticated identity even for containers where that wasn't previously available.

I don't have an issue with that particularly, although it may be somewhat redundant WRT our SecurityContext. My biggest concern would just be that it's behavior doesn't diverge from what we specify due to differences in the wording of the respective specs, especially w.r.t. subtleties about the specific Principal that's returned.

Is this currently in development, or in a final version of the CDI spec?

LieGrue,
strub (with my CDI EG hat on)

What does LieGrue mean? Did a quick Google, but only found things that didn't seem relevant, or were your posts. ;)

Regards,

Will
-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Guillermo González de Agüero
 

Hi,

Guillermo González de Agüero

On Wed, May 31, 2017 at 12:37 PM, Arjan Tijms <arjan.tijms@...> wrote:
I mentioned JPA and that method already ;)

I do wonder where to place unWrap then, as just Principal can't be extended (Java SE type). What we could do for instance is; make the return type getCallerPrincipal as Werner mentioned:


CallerPrincipal callerPrincipal = SecurityContext.getCallerPrincipal();


This CallerPrincipal is NOT the exact Principal set by the HAM or SAM, but only has the same output for getName(). Then, as Mark and Rudy proposed, this type has the unwrap method for the actual type:


MyPrincipal myPrincipal = callerPrincipal.unwrap(MyPrincipal.class);


And it can be used for the functionality Will needed:


WLSPrincipal wlsPrincipal = callerPrincipal.unwrap(WLSPrincipal.class);


Optionally, we could provide 2 convenience methods:


// Return whatever (unknown) principal the HAM or SAM set
Principal myPrincipal = callerPrincipal.getOriginalPrincipal();

// Return whatever (unknown) principal WebLogic used internally
Principal wlsPrincipal = callerPrincipal.getContainerPrincipal();
The benefit I see from that methods is that application will be able to get the know which implementation Principals is it using. But in order to use them to do something useful, the developer will need to know the type at compile time anyway.

I mean, if you need some custom attribute (e.g. CustomPrincipal#getTenantId()), you'll have to cast the object:
CustomPrincipal principal = (CustomPrincipal)callerPrincipal.getOriginalPrincipal();

So I don't see it adds much value over just the CallerPrincipal#unwrap(CustomPrincipal.class) and we are in a later stage with little time. Is there something I'm missing here? Any other advantage from being able to get those raw Principals?




Contrary to what Will raised as potential concern, the CallerPrincipal does not have to be necessarily present in the Subject. For now WebLogic *could* do (but does not have to do):

class SecurityContextImpl implements SecurityContext {
    
    // ...

    public CallerPrincipal getCallerPrincipal() {
        WLSPrincipal wlsPrincipal = ... get from somewhere
        Principal originalPrincipal = ... get from somewhere

        return new CallerPrincipalImpl(originalPrincipal, wlsPrincipal);
    }
}

Thoughts?

Kind regards,
Arjan Tijms















On Wed, May 31, 2017 at 12:19 PM, Mark Struberg via Groups.Io <struberg@...> wrote:
This might also be named in analogue what we have in JPA and Bean Validation, etc:
T unwrap(Class<T>)

We should imo try to keep EE parts as homogenous as possible.

LieGrue,
strub

> Am 31.05.2017 um 12:06 schrieb Werner Keil <werner.keil@...>:
>
> Looks good to me as well.
>
> Would that replace the no-op version currently named getCallerPrincipal() ?
>
> Werner
>





Regards,

Guillermo González de Agüero